我們直接進(jìn)入正題。這個(gè)“UnionFS VS OverlayFS一”的標(biāo)題顯然是個(gè)系列開(kāi)篇。在Linux容器、鏡像分發(fā)、嵌入式系統(tǒng)以及LiveCD這些場(chǎng)景里Union掛載是個(gè)繞不開(kāi)的話題而UnionFS和OverlayFS恰恰對(duì)應(yīng)了這條技術(shù)路線里“曾經(jīng)的經(jīng)典方案”和“當(dāng)前的事實(shí)標(biāo)準(zhǔn)”。這篇我先把兩套方案的實(shí)現(xiàn)思路、核心差異和OverlayFS的落地操作完整鋪開(kāi)系列后面再做深入源碼和行為邊界層面的東西。不管你是剛接觸容器存儲(chǔ)驅(qū)動(dòng)還是正在折騰自研鏡像系統(tǒng)這篇都適合當(dāng)一份比較完整的對(duì)照手冊(cè)來(lái)讀。我一直認(rèn)為搞明白UnionFS和OverlayFS的對(duì)比本質(zhì)上不是“誰(shuí)比誰(shuí)強(qiáng)”這么簡(jiǎn)單而是理解Linux內(nèi)核在“多目錄合并視圖”這個(gè)需求上怎么一步步從復(fù)雜走向簡(jiǎn)潔從用戶態(tài)模塊走向內(nèi)核原生支持。文章會(huì)從背景動(dòng)機(jī)、原理路徑、實(shí)操掛載、特性邊界、問(wèn)題排查這幾個(gè)維度展開(kāi)盡量把每個(gè)關(guān)鍵選擇背后的“為什么”也講清楚。1. 背景Union掛載要解決的核心問(wèn)題1.1 為什么需要聯(lián)合文件系統(tǒng)多個(gè)目錄掛載到同一個(gè)掛載點(diǎn)并且對(duì)外呈現(xiàn)為一個(gè)合并后的單一視圖這就是Union掛載的直觀定義。聽(tīng)起來(lái)好像很簡(jiǎn)單但真正做起來(lái)遠(yuǎn)比想象中麻煩因?yàn)槲募到y(tǒng)的語(yǔ)義遠(yuǎn)比“能看到哪些文件”復(fù)雜得多。最早的強(qiáng)需求來(lái)自LiveCD和Linux發(fā)行版的安裝器一張只讀光盤(pán)作為基礎(chǔ)系統(tǒng)一個(gè)可寫(xiě)的內(nèi)存臨時(shí)目錄作為用戶數(shù)據(jù)層兩者合并成一個(gè)看起來(lái)完整的根文件系統(tǒng)。用戶對(duì)系統(tǒng)做的任何修改都寫(xiě)到臨時(shí)目錄里而光盤(pán)內(nèi)容始終保持只讀。這樣系統(tǒng)既擁有了完整的軟件環(huán)境又不需要把整張光盤(pán)復(fù)制到內(nèi)存盤(pán)上。這種設(shè)計(jì)天然就是分層思想的雛形。容器場(chǎng)景進(jìn)一步放大了這個(gè)需求。Docker鏡像的每一層都是只讀的容器啟動(dòng)時(shí)需要一個(gè)可寫(xiě)層疊加在只讀鏡像層之上并且對(duì)容器內(nèi)部進(jìn)程來(lái)說(shuō)它看到的應(yīng)該是一個(gè)完整的、連續(xù)的根文件系統(tǒng)它甚至感知不到底層有幾個(gè)只讀層。這個(gè)需求如果不用Union掛載就只能“把鏡像層全部復(fù)制一份再合并”代價(jià)極其高昂。UnionFS和OverlayFS本質(zhì)上都是為了解決“多個(gè)只讀層一個(gè)可寫(xiě)層如何組成單一視圖”這個(gè)存儲(chǔ)問(wèn)題而生的。1.2 從UnionFS到OverlayFS一段技術(shù)演進(jìn)的必然UnionFS這個(gè)名字有兩層含義。狹義上它特指由Professor Erez Zadok團(tuán)隊(duì)維護(hù)的那個(gè)歷史悠久的Linux文件系統(tǒng)項(xiàng)目廣義上它代表“文件系統(tǒng)聯(lián)合掛載”這一類技術(shù)。后來(lái)出現(xiàn)的UnionFS-NG是它的后繼實(shí)驗(yàn)版本再往后還有AuFSAnother UnionFSDocker早期版本就是靠AuFS實(shí)現(xiàn)了鏡像分層那段歷史很多老容器工程師都印象深刻。但AuFS始終沒(méi)有進(jìn)入Linux內(nèi)核主線一直作為外部補(bǔ)丁存在這讓發(fā)行版和容器項(xiàng)目都很頭疼內(nèi)核一升級(jí)補(bǔ)丁就得跟著適配穩(wěn)定性完全看維護(hù)者的精力。OverlayFS從另一條路走了過(guò)來(lái)——它被直接合入Linux內(nèi)核從內(nèi)核3.18開(kāi)始提供初始能力并逐步演進(jìn)。內(nèi)核原生的優(yōu)勢(shì)是決定性的不用維護(hù)外部模塊、隨內(nèi)核發(fā)布、社區(qū)持續(xù)打磨。OverlayFS最終取代AuFS成為容器存儲(chǔ)驅(qū)動(dòng)事實(shí)標(biāo)準(zhǔn)這背后不是簡(jiǎn)單的性能對(duì)比而是生態(tài)和可維護(hù)性的全面碾壓。2. 原理拆解兩條不同的技術(shù)實(shí)現(xiàn)路徑2.1 UnionFS的設(shè)計(jì)思路與關(guān)鍵機(jī)制UnionFS的原始設(shè)計(jì)非?！皩W(xué)術(shù)化”它追求的是功能完備把多個(gè)目錄通過(guò)堆疊stacking的方式合并并且對(duì)每一個(gè)成員目錄提供完全一致的POSIX語(yǔ)義支持。為了做到這一點(diǎn)UnionFS需要維護(hù)非常復(fù)雜的目錄項(xiàng)映射關(guān)系記住每個(gè)文件來(lái)自哪個(gè)分支、哪個(gè)層需要在內(nèi)存里建立一棵合并后的目錄樹(shù)并且實(shí)時(shí)追蹤各個(gè)分支的變化。這種全功能設(shè)計(jì)帶來(lái)了一個(gè)致命代價(jià)復(fù)雜度太高。文件查找、重命名、刪除、屬性修改每個(gè)操作都要跨越多個(gè)分支做協(xié)調(diào)大量輔助數(shù)據(jù)結(jié)構(gòu)占內(nèi)存不說(shuō)很多邊界情況處理容易出現(xiàn)不一致。UnionFS在本地測(cè)試?yán)镄阅苌锌傻坏┟鎸?duì)并發(fā)訪問(wèn)、大量小文件操作、跨層重命名鎖競(jìng)爭(zhēng)和路徑解析開(kāi)銷立刻暴露出來(lái)。技術(shù)上它的兩個(gè)代表性機(jī)制是分支優(yōu)先級(jí)branch優(yōu)先級(jí)數(shù)值越小優(yōu)先級(jí)越高和寫(xiě)時(shí)復(fù)制Copy-Up。文件寫(xiě)入時(shí)如果目標(biāo)文件位于低優(yōu)先級(jí)只讀分支UnionFS會(huì)先將整個(gè)文件復(fù)制到高優(yōu)先級(jí)可寫(xiě)分支再對(duì)副本執(zhí)行修改操作。寫(xiě)時(shí)復(fù)制聽(tīng)起來(lái)很美但注意是“整個(gè)文件”復(fù)制不是按塊復(fù)制這在后面OverlayFS的演進(jìn)里仍是核心話題之一。2.2 OverlayFS的設(shè)計(jì)思路與關(guān)鍵機(jī)制OverlayFS的設(shè)計(jì)哲學(xué)在源碼注釋里就寫(xiě)得很直白它不追求“在語(yǔ)義上完全等價(jià)于一個(gè)普通文件系統(tǒng)”而是“在絕大多數(shù)場(chǎng)景下提供足夠好用的合并視圖”。它把組成成員稱為層layer最底層叫l(wèi)owerdir底層目錄最上層可寫(xiě)目錄叫upperdir上層目錄合并后的視圖叫merged目錄合并目錄。結(jié)構(gòu)上它比UnionFS簡(jiǎn)單得多只區(qū)分“可寫(xiě)的upper”和“只讀的lower”不需要維護(hù)多分支的復(fù)雜優(yōu)先級(jí)關(guān)系。OverlayFS的寫(xiě)時(shí)復(fù)制策略更務(wù)實(shí)當(dāng)進(jìn)程對(duì)lower層文件發(fā)起修改操作時(shí)OverlayFS把該文件完整復(fù)制到upper層然后所有后續(xù)修改都發(fā)生在upper層的副本上。原文件在lower層的inode保持不變。這個(gè)策略在大部分容器場(chǎng)景里是合理的因?yàn)槿萜麋R像層的文件極少被修改絕大多數(shù)操作是“新建文件”和“讀取文件”真正觸發(fā)Copy-Up的次數(shù)少之又少。讀取路徑是OverlayFS的另一個(gè)精髓。它不像UnionFS那樣為整個(gè)合并視圖建立獨(dú)立的目錄樹(shù)緩存而是直接在路徑查找時(shí)從上到下依次在upper、lower層中查找。每層本身都是真實(shí)存在的文件系統(tǒng)VFS的dcache目錄項(xiàng)緩存可以正常作用于各層內(nèi)部真正實(shí)現(xiàn)了“各層是自己的文件系統(tǒng)OverlayFS只是組合它們的邏輯”。2.3 兩者核心差異對(duì)照對(duì)比維度UnionFSOverlayFS內(nèi)核集成外部模塊/補(bǔ)丁未進(jìn)入主線內(nèi)核原生3.18引入隨內(nèi)核演進(jìn)分層數(shù)量限制支持多分支數(shù)量可配置lowerdir支持多層可多個(gè)upperdir單層合并視圖緩存維護(hù)獨(dú)立的目錄映射結(jié)構(gòu)不維護(hù)全局映射依賴各層自身dcache寫(xiě)時(shí)復(fù)制范圍整個(gè)文件復(fù)制到高優(yōu)先級(jí)分支整個(gè)文件復(fù)制到upper層執(zhí)行語(yǔ)義盡量完整模擬POSIX接受部分語(yǔ)義差異換取性能與穩(wěn)定主要?dú)v史角色推動(dòng)了聯(lián)合文件系統(tǒng)研究成為容器和Linux發(fā)行版的默認(rèn)方案這張表里最值得關(guān)注的是“執(zhí)行語(yǔ)義”這一行。OverlayFS明確接受了一些非常規(guī)行為比如rename/delete在層間操作時(shí)可能有特殊語(yǔ)義這在后續(xù)的常見(jiàn)問(wèn)題部分會(huì)具體講到。3. 實(shí)操在Linux上掛載OverlayFS3.1 準(zhǔn)備目錄結(jié)構(gòu)紙上談兵沒(méi)有意義直接把環(huán)境搭起來(lái)驗(yàn)證一遍最實(shí)在。我建議你用一臺(tái)Linux虛擬機(jī)或者任意云主機(jī)來(lái)做內(nèi)核版本別太老至少4.x以上推薦5.15以上因?yàn)樾聝?nèi)核補(bǔ)了很多overlay的edge case?；A(chǔ)環(huán)境準(zhǔn)備如下mkdir -p /tmp/overlay-test/{lower,upper,work,merged} echo hello from lower layer /tmp/overlay-test/lower/hello.txt echo lower version /tmp/overlay-test/lower/config.txt echo upper version /tmp/overlay-test/upper/config.txt我在這里故意制造了一個(gè)同名文件場(chǎng)景config.txt同時(shí)存在于lower和upper層mount之后你就能直觀看到上層覆蓋下層的規(guī)則。work目錄是overlay工作目錄它不能和upper、lower、merged重疊這是硬性要求稍后解釋。3.2 掛載命令與參數(shù)詳解用最標(biāo)準(zhǔn)的方式執(zhí)行掛載mount -t overlay overlay -o lowerdir/tmp/overlay-test/lower,upperdir/tmp/overlay-test/upper,workdir/tmp/overlay-test/work /tmp/overlay-test/merged掛載之后查看合并目錄ls /tmp/overlay-test/merged/ cat /tmp/overlay-test/merged/config.txt正常情況下config.txt輸出的是upper version說(shuō)明高優(yōu)先級(jí)層覆蓋低優(yōu)先級(jí)層。你還會(huì)看到hello.txt這就是lower層文件出現(xiàn)在合并視圖里的證據(jù)。關(guān)于參數(shù)的幾個(gè)關(guān)鍵點(diǎn)我補(bǔ)充一下lowerdir支持多個(gè)目錄用冒號(hào)分隔例如lowerdir/lower1:/lower2:/lower3越靠前的目錄優(yōu)先級(jí)越高。這個(gè)順序容易和直覺(jué)相反初始設(shè)置時(shí)建議反復(fù)確認(rèn)。upperdir同時(shí)存在同名文件與目錄時(shí)upper層勝出。合并規(guī)則是upper有就用upper的upper沒(méi)有才在lower里找。workdir必須和upperdir在同一個(gè)文件系統(tǒng)上這是內(nèi)核為了保證Copy-Up操作原子性做的硬限制。如果你試圖把work放在別的文件系統(tǒng)mount會(huì)直接報(bào)Invalid argument。merged掛載點(diǎn)自身也可以是普通目錄不需要預(yù)先為空但掛載后原目錄內(nèi)容會(huì)被隱藏類似普通mount覆蓋行為。3.3 驗(yàn)證Copy-Up行為掛載只是開(kāi)始真正有趣的是看看寫(xiě)時(shí)復(fù)制到底怎么運(yùn)作。先查看lower和upper層的文件inode信息stat -c %i %h %s /tmp/overlay-test/lower/hello.txt stat -c %i %h %s /tmp/overlay-test/merged/hello.txt這時(shí)兩者inode相同因?yàn)檫€沒(méi)有任何寫(xiě)入merged里的hello.txt本質(zhì)上就是lower文件的引用?，F(xiàn)在通過(guò)merged目錄修改這個(gè)文件echo modified via merged /tmp/overlay-test/merged/hello.txt這時(shí)再看stat -c %i %h %s /tmp/overlay-test/lower/hello.txt stat -c %i %h %s /tmp/overlay-test/merged/hello.txt ls -l /tmp/overlay-test/upper/你會(huì)看到upper目錄里出現(xiàn)了一個(gè)新的hello.txt內(nèi)容和merged里一致但inode和lower里的完全不同。這就是Copy-Up的完整過(guò)程修改觸發(fā)復(fù)制復(fù)制發(fā)生在底層然后修改作用于副本。這里有個(gè)值得思考的細(xì)節(jié)文件被復(fù)制到upper層之后它是作為一個(gè)全新文件存在的。如果lower層的原始文件后來(lái)被外部程序修改merged視圖里不會(huì)再看到這個(gè)變化因?yàn)閡pper層的副本已經(jīng)“遮蔽”了lower層原文件。這就是為什么容器鏡像層不可變才是分層賴以生存的基礎(chǔ)——一旦lower層發(fā)生變化視圖一致性就無(wú)法保證。這也是我在生產(chǎn)環(huán)境里堅(jiān)持“鏡像層只增不改”的原因。4. 特性擴(kuò)展與內(nèi)核參數(shù)邊界4.1 掛載選項(xiàng)index、redirect_dir與metacopyOverlayFS遠(yuǎn)不止一個(gè)簡(jiǎn)單的合并掛載能力。從內(nèi)核4.x開(kāi)始一系列掛載選項(xiàng)讓它的行為更加精細(xì)化理解這些選項(xiàng)對(duì)生產(chǎn)環(huán)境選型至關(guān)重要。indexon啟用索引特性為每個(gè)復(fù)制到upper層的文件建立索引防止硬鏈接在層間復(fù)制后產(chǎn)生不一致。Docker的overlay2驅(qū)動(dòng)默認(rèn)就依賴這個(gè)特性來(lái)保證鏡像層共享時(shí)的硬鏈接安全。開(kāi)啟方式是在掛載選項(xiàng)里加indexonmount -t overlay overlay -o lowerdir...,upperdir...,workdir...,indexon /merged。注意index開(kāi)啟后upper目錄里會(huì)多出一個(gè)#index目錄這是內(nèi)核管理索引用的不要手動(dòng)去動(dòng)它。redirect_diron允許重定向目錄。沒(méi)有這個(gè)選項(xiàng)時(shí)如果rename一個(gè)目錄OverlayFS需要復(fù)制整個(gè)目錄樹(shù)到upper層代價(jià)非常大。開(kāi)啟后內(nèi)核可以創(chuàng)建一個(gè)“重定向”的目錄項(xiàng)指向原目錄在lower層的位置這樣rename操作就變成了輕量級(jí)的元數(shù)據(jù)修改。但這個(gè)選項(xiàng)帶來(lái)的語(yǔ)義復(fù)雜度和性能問(wèn)題是長(zhǎng)期爭(zhēng)議點(diǎn)很多生產(chǎn)環(huán)境為了穩(wěn)定寧愿關(guān)掉它。metacopyon這是OverlayFS近幾個(gè)內(nèi)核版本里一個(gè)很強(qiáng)的優(yōu)化特性。開(kāi)啟后Copy-Up不再?gòu)?fù)制整個(gè)文件內(nèi)容而是只復(fù)制文件的元數(shù)據(jù)比如屬主、權(quán)限、大小到upper層并設(shè)置一個(gè)特殊標(biāo)志。當(dāng)進(jìn)程真正執(zhí)行寫(xiě)操作時(shí)再觸發(fā)完整的數(shù)據(jù)復(fù)制。它極大地優(yōu)化了“低頻元數(shù)據(jù)變更”場(chǎng)景比如chmod、chown不需要把巨大的數(shù)據(jù)文件復(fù)制一遍。代價(jià)是讀取文件時(shí)多了一層間接性并且一些需要物理讀取文件內(nèi)容的操作如mmap可能會(huì)繞過(guò)優(yōu)化路徑。4.2 掛載選項(xiàng)對(duì)行為的影響選項(xiàng)開(kāi)啟后的變化風(fēng)險(xiǎn)與注意點(diǎn)indexon避免硬鏈接層間復(fù)制問(wèn)題upper層多出索引目錄不能隨意刪除redirect_diron目錄rename操作輕量化語(yǔ)義復(fù)雜部分場(chǎng)景影響NFS導(dǎo)出metacopyon元數(shù)據(jù)變更不觸發(fā)數(shù)據(jù)復(fù)制數(shù)據(jù)讀取多一層間接可能干擾部分監(jiān)控工具volatilemount狀態(tài)變化不持久化重啟即丟僅適合可重建場(chǎng)景生產(chǎn)慎用volatile是另一個(gè)需要單獨(dú)說(shuō)明的掛載選項(xiàng)它告訴OverlayFS所有upper層的修改在系統(tǒng)重啟后可以丟失。這聽(tīng)起來(lái)很可怕但在某些場(chǎng)景下非常有用比如系統(tǒng)做OTA升級(jí)時(shí)臨時(shí)數(shù)據(jù)層不要求持久化重啟后重新構(gòu)建即可。開(kāi)啟方式為volatile掛載選項(xiàng)但務(wù)必要知道它的代價(jià)是“非正常關(guān)機(jī)可能連正常同步都沒(méi)做全”。這些特性疊加之后OverlayFS的能力已經(jīng)不是“簡(jiǎn)單的層疊合并”能概括的了。選型時(shí)我建議的原則是能默認(rèn)就默認(rèn)只在遇到具體性能瓶頸時(shí)用最小范圍的選項(xiàng)變更去試錯(cuò)一次只改一個(gè)選項(xiàng)觀察足夠長(zhǎng)的時(shí)間再下結(jié)論。5. 常見(jiàn)問(wèn)題與排查實(shí)錄5.1 Copy-Up引發(fā)的性能陷阱OverlayFS最容易被詬病的就是Copy-Up性能。明明只修改了一個(gè)字節(jié)為什么耗時(shí)和復(fù)制整個(gè)文件一樣因?yàn)镺verlayFS拷貝的粒度就是“整個(gè)文件”不是按塊或按字節(jié)。如果一個(gè)容器鏡像里有大的日志文件或數(shù)據(jù)庫(kù)文件應(yīng)用每次追加寫(xiě)入都會(huì)把整個(gè)文件從lower復(fù)制到upper表現(xiàn)就是單次寫(xiě)入慢得離譜。排查這類問(wèn)題有個(gè)很實(shí)用的技巧用perf或者bcc追蹤文件系統(tǒng)層級(jí)的overlay_copy_up事件可以快速確認(rèn)寫(xiě)入是否觸發(fā)了Copy-Up。我遇到過(guò)一個(gè)真實(shí)案例一個(gè)應(yīng)用反復(fù)打開(kāi)一個(gè)巨大的二進(jìn)制模型文件進(jìn)行元數(shù)據(jù)修改metacopy未開(kāi)啟時(shí)每次操作都導(dǎo)致幾十MB的完整復(fù)制應(yīng)用啟動(dòng)時(shí)間被拖慢到分鐘級(jí)。開(kāi)啟metacopy后啟動(dòng)時(shí)間銳減到幾秒。遇到Copy-Up性能瓶頸時(shí)的應(yīng)對(duì)思路把頻繁寫(xiě)入的文件提前放到upper層避免運(yùn)行時(shí)Copy-Up。使用metacopyon降低元數(shù)據(jù)修改的場(chǎng)景開(kāi)銷。從設(shè)計(jì)上避免修改鏡像層內(nèi)的大文件把可寫(xiě)數(shù)據(jù)獨(dú)立掛載到單獨(dú)卷。5.2 磁盤(pán)空間統(tǒng)計(jì)為何“不對(duì)”在merged目錄里執(zhí)行df -h看到的容量統(tǒng)計(jì)通常來(lái)自u(píng)pperdir所在文件系統(tǒng)而不是整個(gè)合并視圖的總?cè)萘?。這在容器場(chǎng)景里就表現(xiàn)為容器內(nèi)看到根文件系統(tǒng)容量很大但實(shí)際可寫(xiě)層很小寫(xiě)入稍微多一下就報(bào)No space left on device很讓人困惑。為什么會(huì)這樣因?yàn)閛verlay并不真正分配自己的存儲(chǔ)空間merged視圖里的所有數(shù)據(jù)都實(shí)際存儲(chǔ)在upper或lower所在的底層文件系統(tǒng)上。df只能反映某個(gè)掛載點(diǎn)的物理存儲(chǔ)信息overlay的掛載點(diǎn)并沒(méi)有自己的塊分配表內(nèi)核就“從上往下”報(bào)告了upperdir所在文件系統(tǒng)的容量。Docker早期采用overlay驅(qū)動(dòng)時(shí)就踩過(guò)這個(gè)坑容器內(nèi)df看到宿主機(jī)磁盤(pán)大小但可寫(xiě)層配額由宿主機(jī)限制一旦寫(xiě)滿就報(bào)錯(cuò)?，F(xiàn)在Docker用pids和storage配額配合解決這個(gè)問(wèn)題但概念上依然要認(rèn)清overlay的容量不是它自己的而是upper層的容量。如果要查看overlay中某個(gè)文件到底占了哪一層的空間可以使用toybox或busybox里的du配合ls -l做判斷觀察文件的inode變化和目錄層級(jí)關(guān)系即可。生產(chǎn)環(huán)境里我建議監(jiān)控Upper目錄的實(shí)際用量而不是merged視圖里的統(tǒng)計(jì)值。5.3 lower層被外部修改導(dǎo)致的不一致OverlayFS的一個(gè)基本假設(shè)是lower層在掛載期間保持穩(wěn)定不能隨意修改。但在實(shí)踐中經(jīng)常有人掛載后直接改lower目錄里的文件導(dǎo)致merged視圖出現(xiàn)各種詭異行為文件內(nèi)容一半新一半舊inode匹配錯(cuò)亂甚至某些文件在merged中“消失”。這類問(wèn)題排查起來(lái)非常隱蔽因?yàn)閂FS層看到的是OverlayFS維護(hù)的內(nèi)部狀態(tài)底層inode變化后overlay的dentry可能已經(jīng)失效或者緩存不匹配。應(yīng)對(duì)辦法只有兩個(gè)嚴(yán)格要求所有寫(xiě)操作走merged視圖經(jīng)overlay的Copy-Up邏輯處理。如果確實(shí)需要改lower內(nèi)容必須先卸載overlay掛載點(diǎn)修改完后再重新掛載。在容器環(huán)境下這基本就意味著重建容器或鏡像層。我在本地測(cè)試時(shí)就遇到過(guò)類似場(chǎng)景我直接在lower里替換了一個(gè)配置文件隨后merged里讀出的文件內(nèi)容正確但stat顯示的鏈接數(shù)不對(duì)而echo重定向?qū)懭胫髐pper里新建了文件lower里的舊文件卻還殘留。這種“半更新”狀態(tài)是所有聯(lián)合文件系統(tǒng)的大忌生產(chǎn)環(huán)境一定不要這么用。5.4 文件刪除為何不釋放lower層空間另一個(gè)高頻困惑是在merged里刪除一個(gè)原本位于lower層的文件磁盤(pán)空間卻沒(méi)有釋放。原因很簡(jiǎn)單——?jiǎng)h除操作在OverlayFS里是通過(guò)whiteout白色占位符實(shí)現(xiàn)的它在上層創(chuàng)建一個(gè)特殊標(biāo)記表示“這個(gè)文件名已刪除”而不是真的把lower層的文件刪除。這個(gè)whiteout機(jī)制的具體表現(xiàn)是在upper目錄里你會(huì)看到一個(gè)字符設(shè)備文件它的設(shè)備號(hào)為0/0或者在一個(gè)普通目錄上設(shè)置了trusted.overlay.whiteout這些擴(kuò)展屬性。這在容器場(chǎng)景下其實(shí)很正常Docker刪除容器內(nèi)的文件只是把該文件標(biāo)記為已刪除鏡像層里的原始數(shù)據(jù)依然在所以鏡像不會(huì)因?yàn)槿萜鲀?nèi)刪除操作而變小。鏡像大小只會(huì)隨著鏡像層本身的重建而變化。如果你真的需要釋放空間辦法是把構(gòu)建鏡像時(shí)的RUN指令改為在同一層里處理或者用docker export重新打扁平鏡像。但要注意這并不屬于OverlayFS本身能解決的問(wèn)題它的語(yǔ)義就是“上層屏蔽下層”不是“上層銷毀下層”。6. 給初學(xué)者的選型建議與個(gè)人體會(huì)先給個(gè)直接結(jié)論如果你的場(chǎng)景是容器、云原生、系統(tǒng)鏡像疊加這類主流需求直接選OverlayFS別再用UnionFS系列或者自己折騰用戶態(tài)聯(lián)合掛載方案。理由很簡(jiǎn)單清晰內(nèi)核支持、默認(rèn)集成、大型社區(qū)驗(yàn)證這些都是硬指標(biāo)。如果你在做嵌入式或硬件受限的環(huán)境需要評(píng)估的其實(shí)是overlay的性能開(kāi)銷和內(nèi)存占用是否可接受。實(shí)測(cè)來(lái)看overlay的靜態(tài)內(nèi)存開(kāi)銷非常小主要消耗集中在Copy-Up瞬間的臨時(shí)I/O緩沖區(qū)上正常工況下不會(huì)有太大問(wèn)題。相比自己用bind mount或者FUSE方案解決overlay的穩(wěn)定性和性能都要好很多。我個(gè)人在實(shí)際操作中最深的體會(huì)是OverlayFS的“保持一致”遠(yuǎn)比“追求性能”重要。很多人一上來(lái)就琢磨metacopy、redirect_dir這些優(yōu)化選項(xiàng)卻忽略了掛載層穩(wěn)定性的前提條件最終導(dǎo)致線上出問(wèn)題。建議新接觸的朋友先按最淳樸的掛載方式跑通全部實(shí)驗(yàn)再逐項(xiàng)打開(kāi)特性理解每個(gè)選項(xiàng)改變了什么再去談優(yōu)化。另外一個(gè)實(shí)用心得是排查overlay問(wèn)題時(shí)別只盯著內(nèi)核日志先檢查掛載參數(shù)和掛載狀態(tài)。很多時(shí)候dmesg里根本沒(méi)有錯(cuò)誤信息問(wèn)題就是lower層被動(dòng)了、路徑選錯(cuò)了、或者workdir和upperdir跨文件系統(tǒng)了。仔細(xì)檢查/proc/mounts里的掛載選項(xiàng)往往比盲目調(diào)試更高效。這個(gè)系列的第一篇到這里算是對(duì)UnionFS和OverlayFS的背景、原理和基礎(chǔ)操作給了個(gè)全景。后續(xù)我會(huì)繼續(xù)把這個(gè)話題往深處推OverlayFS的inode復(fù)用機(jī)制、與頁(yè)緩存的交互行為、NFS導(dǎo)出場(chǎng)景下的特性支持、以及Docker/containerd存儲(chǔ)驅(qū)動(dòng)選型背后的完整邏輯。有興趣的可以先把本篇的實(shí)驗(yàn)操作做一遍親手看看Copy-Up的表現(xiàn)和掛載參數(shù)的變化后面聊到行為細(xì)節(jié)時(shí)你會(huì)理解得更快。