Docker

覆蓋儲存驅動程序內部

  • April 7, 2019

這個問題的後續行動。

我對Docker 儲存驅動程序的進一步閱讀表明,該overlay驅動程序使用硬連結實現將所有映像層合併到較低層,這會導致 inode 使用率過高。有人可以解釋一下嗎?據我所知,創建硬連結不會創建新的 inode。

OverlayFS 是一個聯合文件系統,在 Docker 級別有兩個儲存驅動程序使用它:原始/舊版本overlay名為overlay2. 在 OverlayFS 中,有一個以只讀方式公開的低級目錄。在這個目錄之上是上層目錄,它允許讀寫訪問。這些目錄中的每一個都稱為一個層。低級目錄和高級目錄的組合視圖顯示為一個單元,稱為“合併”目錄。

較新的overlay2儲存驅動程序本機支持多達 128 個此類層。較舊的overlay驅動程序一次只能使用兩層。由於大多數 Docker 鏡像都是使用多層建構的,因此這個限制相當重要。為了解決這個限制,每一層都被實現為一個模擬完整圖像的單獨目錄。

為了檢查我的測試系統上的差異,我從 Docker Hub 中提取了“ubuntu”映像,並檢查了驅動程序overlay2overlay驅動程序之間目錄結構的差異:

[root@testvm1 overlay2]$ ls */diff
4864f14e58c1d6d5e7904449882b9369c0c0d5e1347b8d6faa7f40dafcc9d231/diff:
run

4abcfa714b4de6a7f1dd092070b1e109e8650a7a9f9900b6d4c3a7ca441b8780/diff:
var

a58c4e78232ff36b2903ecaab2ec288a092e6fc55a694e5e2d7822bf98d2c214/diff:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

c3f1a237c46ed330a2fd05ab2a0b6dcc17ad08686bd8dc49ecfada8d85b93a00/diff:
etc  sbin  usr  var


[root@testvm1 overlay]# ls */root/
001311c618ad7b94d4dc9586f26e421906e7ebf5c28996463a355abcdcd501bf/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

048f81f400f7d74f969c4fdaff6553c782d12c04890ad869d75313505c868fbc/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

8060f0c647f24050e1a4bff71096ffdf9665bff26e6187add87ecb8a18532af9/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

fbdef944657234468ee55b12c7910aa495d13936417f9eb905cdc39a40fb5361/root/:
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

overlay表示中,每一層都模擬一個完整的圖像,而這些overlay2層只包含層之間的確切差異。在overlay驅動程序的方法中,硬連結被用作節省不同層之間空間的一種方式。但是,這種方法還不夠完善,當圖像數據中包含符號連結、字元設備等特殊文件時,需要新的inode。這可以快速增加大量的 inode。

overlay2我的測試系統上的和驅動程序之間的inode分佈overlay如下圖所示。

[root@testvm1 overlay2]$ du --inodes -s *
8       4864f14e58c1d6d5e7904449882b9369c0c0d5e1347b8d6faa7f40dafcc9d231
27      4abcfa714b4de6a7f1dd092070b1e109e8650a7a9f9900b6d4c3a7ca441b8780
3311    a58c4e78232ff36b2903ecaab2ec288a092e6fc55a694e5e2d7822bf98d2c214
1       backingFsBlockDev
25      c3f1a237c46ed330a2fd05ab2a0b6dcc17ad08686bd8dc49ecfada8d85b93a00
5       l

[root@testvm1 overlay]# du --inodes -s *
3298    001311c618ad7b94d4dc9586f26e421906e7ebf5c28996463a355abcdcd501bf
783     048f81f400f7d74f969c4fdaff6553c782d12c04890ad869d75313505c868fbc
768     8060f0c647f24050e1a4bff71096ffdf9665bff26e6187add87ecb8a18532af9
765     fbdef944657234468ee55b12c7910aa495d13936417f9eb905cdc39a40fb5361

在我的系統上,inode 的總數overlay2達到 3378。使用overlay,這個計數上升到 5615。這個值考慮的是單個鏡像並且沒有容器在執行,因此具有大量 docker 容器和鏡像的大型系統可能會很快達到支持文件系統(XFS 或 EXT4,目錄所在的/var/lib/docker/overlay位置)。

由於這個原因,較新的overlay2儲存驅動程序目前是大多數新安裝的推薦選項。該overlay驅動程序自 Docker v18.09 起已棄用,預計將在未來版本中刪除。

引用自:https://unix.stackexchange.com/questions/510931