覆蓋儲存驅動程序內部
這個問題的後續行動。
我對Docker 儲存驅動程序的進一步閱讀表明,該
overlay
驅動程序使用硬連結實現將所有映像層合併到較低層,這會導致 inode 使用率過高。有人可以解釋一下嗎?據我所知,創建硬連結不會創建新的 inode。
OverlayFS 是一個聯合文件系統,在 Docker 級別有兩個儲存驅動程序使用它:原始/舊版本
overlay
名為overlay2
. 在 OverlayFS 中,有一個以只讀方式公開的低級目錄。在這個目錄之上是上層目錄,它允許讀寫訪問。這些目錄中的每一個都稱為一個層。低級目錄和高級目錄的組合視圖顯示為一個單元,稱為“合併”目錄。較新的
overlay2
儲存驅動程序本機支持多達 128 個此類層。較舊的overlay
驅動程序一次只能使用兩層。由於大多數 Docker 鏡像都是使用多層建構的,因此這個限制相當重要。為了解決這個限制,每一層都被實現為一個模擬完整圖像的單獨目錄。為了檢查我的測試系統上的差異,我從 Docker Hub 中提取了“ubuntu”映像,並檢查了驅動程序
overlay2
和overlay
驅動程序之間目錄結構的差異:[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 起已棄用,預計將在未來版本中刪除。