1. 故障現(xiàn)場(chǎng)服務(wù)器重啟后磁盤空間憑空蒸發(fā)fsck 卻顯示一切正常上個(gè)月處理了一起挺典型的 ext4 文件系統(tǒng)故障先說(shuō)現(xiàn)象一臺(tái)跑著數(shù)據(jù)采集服務(wù)的 Linux 服務(wù)器某天意外斷電重啟后業(yè)務(wù)日志開始報(bào)磁盤寫入失敗No space left on device。我登上去一看df -h顯示根分區(qū)用了 92%但詭異的是du -sh去統(tǒng)計(jì)各目錄占用加起來(lái)滿打滿算也就 60% 出頭。中間這 30% 左右的空間差不多 200 多 GB就像憑空蒸發(fā)了一樣。第一時(shí)間想到的肯定是文件系統(tǒng)異常比如有文件被刪除但空間未釋放也就是常說(shuō)的斷尾問(wèn)題或者 inode 表有問(wèn)題。于是按老套路走了一遍修復(fù)流程先把相關(guān)服務(wù)停掉盡量讓文件系統(tǒng)處于靜止?fàn)顟B(tài)。執(zhí)行umount卸載分區(qū)因?yàn)檫@是根分區(qū)沒(méi)法直接卸載我進(jìn)的是 rescue 模式用 live 系統(tǒng)掛載的。運(yùn)行fsck.ext4 -fy /dev/sda3強(qiáng)制檢查修復(fù)。結(jié)果很有意思fsck 跑了兩遍第一遍檢查花了大概 40 分鐘輸出了一堆 stage 檢查日志但沒(méi)有報(bào)告任何 block 或 inode 的錯(cuò)誤也沒(méi)有清理任何孤兒文件。第二遍再跑直接顯示 clean。然而重新掛載回系統(tǒng)df -h一看分區(qū)使用率紋絲不動(dòng)還是 92%。這時(shí)候我才意識(shí)到問(wèn)題遠(yuǎn)不是 fsck 能解決的。它檢查的是文件系統(tǒng)的結(jié)構(gòu)性完整性但對(duì) ext4 的延遲分配delayed allocation機(jī)制在異常斷電后留下的臟數(shù)據(jù)和邏輯空洞基本無(wú)能為力。這篇文章就完整復(fù)盤一下這次排查的經(jīng)過(guò)、背后的文件系統(tǒng)原理以及最后通過(guò) ext4 調(diào)試工具手動(dòng)修復(fù)的完整路徑。先說(shuō)結(jié)論方便不想看過(guò)程的朋友直接抄作業(yè)這類問(wèn)題的根源在于 ext4 的delalloc特性與日志journal機(jī)制在崩潰恢復(fù)時(shí)的交互方式排查鏈路是df對(duì)比du確認(rèn)空間差異再用dumpe2fs觀察文件系統(tǒng)保留塊和未使用塊數(shù)量最后用debugfs手動(dòng)定位并清理斷尾塊。2. ext4 延遲分配機(jī)制空間消失的根源不在刪除而在寫一半2.1 延遲分配到底延遲的是什么要理解這次故障得先搞明白 ext4 延遲分配的工作方式。傳統(tǒng) ext3 文件系統(tǒng)寫數(shù)據(jù)時(shí)內(nèi)核會(huì)為每個(gè) write 請(qǐng)求立即分配磁盤塊也就是說(shuō)你調(diào)用write()的時(shí)候文件系統(tǒng)馬上在磁盤上找一塊空間把數(shù)據(jù)放進(jìn)去然后更新元數(shù)據(jù)inode 的塊指針。ext4 默認(rèn)啟用的延遲分配mount 參數(shù)delalloc換了一套思路write()只是把數(shù)據(jù)寫進(jìn)內(nèi)核的 page cache并不立即分配磁盤塊。文件系統(tǒng)會(huì)把這些臟頁(yè)攢在內(nèi)存里等到合適的時(shí)機(jī)——比如超過(guò)一定時(shí)間、緩存壓力大、或者顯式調(diào)用fsync/sync——才一次性把數(shù)據(jù)刷盤并在這時(shí)候批量分配磁盤塊。這個(gè)設(shè)計(jì)是為了解決連續(xù)寫入場(chǎng)景下的磁盤碎片問(wèn)題。因?yàn)閿?shù)據(jù)先在內(nèi)存里攢著文件系統(tǒng)能看到完整的寫入模式能分配連續(xù)的塊還能減少元數(shù)據(jù)更新次數(shù)。正常運(yùn)行時(shí)性能確實(shí)更好我在基準(zhǔn)測(cè)試?yán)锟吹降捻樞驅(qū)懶阅芴嵘蠹s有 15% 到 30% 左右延遲分配功不可沒(méi)。但代價(jià)就是在數(shù)據(jù)落盤和元數(shù)據(jù)更新之間存在一個(gè)窗口期。這個(gè)窗口期里page cache 里的數(shù)據(jù)和磁盤上的 inode 信息是脫節(jié)的。如果此時(shí)斷電就可能導(dǎo)致兩類問(wèn)題數(shù)據(jù)丟失page cache 沒(méi)刷盤的數(shù)據(jù)直接沒(méi)了?？臻g記賬出錯(cuò)數(shù)據(jù)在 page cache 里時(shí)文件系統(tǒng)已經(jīng)為它預(yù)留了邏輯塊號(hào)邏輯上是連續(xù)的但物理塊還沒(méi)來(lái)得及分配。崩潰恢復(fù)后這些物理塊可能變成被 inode 引用但沒(méi)有實(shí)際分配或已經(jīng)被分配但 inode 信息未更新的中間狀態(tài)。這兩個(gè)問(wèn)題平時(shí)不會(huì)有感覺因?yàn)?ext4 的 journal 機(jī)制會(huì)記錄元數(shù)據(jù)事務(wù)重啟后 journal 回放能恢復(fù)大部分一致性。延遲分配初期的 ext4 在這方面有 bug著名的 delayed allocation ext4 斷電損壞 問(wèn)題后來(lái)通過(guò)引入ext4_writepages的塊預(yù)留機(jī)制基本解決了。但殘余風(fēng)險(xiǎn)依然存在這就是斷尾問(wèn)題的溫床。2.2 斷尾問(wèn)題的本質(zhì)inode 引用了不存在的塊或塊被標(biāo)記但無(wú)歸屬所謂斷尾我理解的更準(zhǔn)確描述是文件系統(tǒng)元數(shù)據(jù)層面出現(xiàn)了不一致具體表現(xiàn)有兩類第一類inode 里記錄的塊總數(shù)大于實(shí)際分配的物理塊。這種情況一般發(fā)生在崩潰瞬間文件系統(tǒng)已經(jīng)更新了 inode 的 i_size文件大小字段但塊分配表block bitmap還沒(méi)來(lái)得及同步。從用戶空間看文件大小正常但那些塊其實(shí)是幽靈塊沒(méi)有真正的物理對(duì)應(yīng)。第二類block bitmap 中標(biāo)記為已分配的塊實(shí)際上沒(méi)有 inode 引用它們。這是延遲分配的鏡像問(wèn)題——塊已經(jīng)被分配出去但還沒(méi)來(lái)得及寫入 inode 的指針表崩潰后這一塊就變成了孤兒塊。我遇到的這次故障真實(shí)情況是第二類。用dumpe2fs -h /dev/sda3查看時(shí)Free blocks的數(shù)量比df計(jì)算出來(lái)的可用空間少了將近 25 萬(wàn)個(gè)塊一個(gè)塊組 4K差不多 1GB 一級(jí)而這些塊在成功掛載后又被標(biāo)記為已分配導(dǎo)致新數(shù)據(jù)寫入時(shí)ext4 認(rèn)為磁盤已滿。fsck 為什么查不出來(lái)因?yàn)?fsck 檢查的是文件系統(tǒng)的結(jié)構(gòu)性沖突——比如兩個(gè) inode 引用同一個(gè)塊、bitmap 與 inode 不匹配、目錄項(xiàng)丟失等。而延遲分配斷尾問(wèn)題可能并不存在結(jié)構(gòu)性沖突只是邏輯上的空間泄漏塊確實(shí)被標(biāo)記已分配也確實(shí)有一個(gè) inode 聲稱屬于它但 inode 的映射表里沒(méi)有這個(gè)塊。這在 fsck 眼中不算錯(cuò)誤。這個(gè)理解非常關(guān)鍵fsck 不是空間泄漏檢查工具它是結(jié)構(gòu)一致性檢查工具。如果你的文件系統(tǒng)看起來(lái)結(jié)構(gòu)正常但邏輯上有幽靈塊fsck 永遠(yuǎn)不會(huì)管它。3. 從 df 到 debugfs定位斷尾空間的完整排查鏈路3.1 用數(shù)據(jù)說(shuō)話df、du、dumpe2fs 三方對(duì)賬排查的第一步永遠(yuǎn)是對(duì)賬。不要憑感覺猜用數(shù)據(jù)把差異量化出來(lái)。# 查看文件系統(tǒng)角度統(tǒng)計(jì)的磁盤空間 df -h /data # 查看目錄樹實(shí)際占用的磁盤空間 du -shx --exclude/proc --exclude/sys --exclude/dev --exclude/run /如果df遠(yuǎn)大于du說(shuō)明確實(shí)存在空間泄漏。但這個(gè)差異也可能是正在運(yùn)行但未刷盤的進(jìn)程占用比如刪除了文件但進(jìn)程還持有 fd或正在寫的文件還沒(méi)落盤。所以在對(duì)賬前最好先停掉所有業(yè)務(wù)進(jìn)程并執(zhí)行sync強(qiáng)制落盤。第二步用dumpe2fs看文件系統(tǒng)自己記錄的統(tǒng)計(jì)信息dumpe2fs -h /dev/sda3重點(diǎn)看這幾項(xiàng)Free blocks文件系統(tǒng)認(rèn)為還有多少塊可用。Block count總塊數(shù)。Reserved block count保留塊數(shù)默認(rèn) 5%。Free inodes可用 inode 數(shù)。如果Free blocks的數(shù)值偏小且與df輸出的 Avail 空間對(duì)不上基本可以確定塊分配層出現(xiàn)了泄漏。我把三方數(shù)據(jù)列了個(gè)對(duì)賬單統(tǒng)計(jì)來(lái)源結(jié)果備注df -h已用 92%剩余 8%用戶空間看到的視野du -sh實(shí)際文件占用約 60%目錄樹掃描結(jié)果dumpe2fs Free blocks占總塊數(shù) 6%遠(yuǎn)低于 du 推斷的可用量文件系統(tǒng)內(nèi)部的記賬差異非常明顯。df 是站在文件系統(tǒng)塊分配層的角度報(bào)數(shù)的du 是從 inode 和目錄樹角度統(tǒng)計(jì)的。兩者差異巨大說(shuō)明有大量塊被分配了但沒(méi)有任何文件引用——這就是典型的斷尾空間。3.2 用 debugfs 手動(dòng)驗(yàn)證幽靈塊是否存在光看統(tǒng)計(jì)還不夠得坐實(shí)這些塊確實(shí)有主無(wú)實(shí)。我用debugfs逐步排查。# 進(jìn)入 debugfs 交互模式只讀打開設(shè)備一定要加 -R 或者手動(dòng)用 open -f debugfs /dev/sda3在 debugfs 交互界面里可以執(zhí)行如下命令核實(shí)# 查看塊組信息找出哪些塊組有大量已分配但文件系統(tǒng)認(rèn)為空閑的塊 stats塊組block group是 ext4 管理塊的基礎(chǔ)單元每個(gè)塊組有獨(dú)立的 bitmap。如果斷尾問(wèn)題集中出現(xiàn)在某個(gè)塊組說(shuō)明寫入高峰撞擊到了特定的塊組分配邊界。更直接的做法是遍歷所有 inode檢查它們的塊映射是否存在偽分配。這里有一個(gè)基于debugfs的腳本思路# 列出所有已分配的 inode debugfs -R lsdel /dev/sda3lsdel是文件系統(tǒng)排障的隱藏功臣它專門列出那些已被刪除但仍然被進(jìn)程持有引用、或者孤兒化處理的 inode。正常文件系統(tǒng)的lsdel輸出應(yīng)該基本為空一旦有內(nèi)容配合du的差異就能交叉驗(yàn)證。我在這次故障中發(fā)現(xiàn)lsdel輸出了 3 個(gè) inode。刪除它們并沒(méi)有直接釋放那 200 多 GB 空間——它們是結(jié)構(gòu)性問(wèn)題但不是空間泄漏的大頭。真正的大頭要這樣找在 debugfs 中執(zhí)行ex /dev/sda3或?qū)懸欢文_本遍歷freeblocks。不過(guò) debugfs 的原生命令有限我采用的是先備份、后 mmap 遍歷法# 用 debugfs 的 dump 命令備份關(guān)鍵元數(shù)據(jù) debugfs -R dump_inode / /dev/sda3 /tmp/root_inode.txt備份完成后重點(diǎn)排查常規(guī)手段查不到的地方所有看起來(lái)已分配卻無(wú)法在目錄樹中定位的文件。所有 inode 中指向的 logical block offsets 對(duì)應(yīng)的 physical block 是否真實(shí)存在。塊組 bitmap 中標(biāo)記為 1 的塊能否通過(guò) inode 的塊映射反向定位到一個(gè)具體文件。這一步純手工做工作量巨大但理念要清楚斷尾塊的特點(diǎn)就是能證明它已分配但無(wú)法反向定位到任何文件路徑。只要能確認(rèn)這一點(diǎn)就足夠判死刑。3.3 fsck 到底查了什么它為什么放過(guò)這些幽靈塊這可能是大家最困惑的地方。明明有幾十萬(wàn)塊處于非法狀態(tài)fsck 跑了好幾遍為什么一聲不吭原因在于 fscke2fsck的檢查模型。它的核心是這幾個(gè) passPass 1檢查 inode 和 block bitmap 的一致性每個(gè)塊只能被一個(gè) inode 引用。Pass 2檢查目錄結(jié)構(gòu)是否完整。Pass 3檢查目錄連接性處理孤兒目錄。Pass 4檢查 inode 引用計(jì)數(shù)。Pass 5檢查塊組摘要信息。斷尾空間的問(wèn)題在于塊 bitmap 是準(zhǔn)確的——它標(biāo)記了這個(gè)塊已被分配而 inode 的映射也是自洽的——它只是沒(méi)引用這塊區(qū)域。從 bitmap 的角度看塊的歸屬符合規(guī)則有 inode 指向它從 inode 的角度看它只是少引用了一些塊。兩者之間確實(shí)存在空間歸于 nobody的情況但 e2fsck 不會(huì)主動(dòng)去驗(yàn)證每個(gè)已分配塊是否一定能通過(guò)某種路徑找到對(duì)應(yīng)文件。因?yàn)檫@種全量反向驗(yàn)證在工程上是不可接受的——全盤塊數(shù)動(dòng)輒上億逐個(gè)反查 inode 的時(shí)間代價(jià)太大。所以查不出來(lái)不是 fsck 蠢而是它的設(shè)計(jì)目標(biāo)里就沒(méi)有檢測(cè)邏輯空間泄漏這一項(xiàng)。它的責(zé)任是保證結(jié)構(gòu)可恢復(fù)而不是保證空間零浪費(fèi)。3.4 根分區(qū)和 RAW 驅(qū)動(dòng)器的一個(gè)順帶提醒chkdsk 救不了 ext4排查過(guò)程中我注意到一些網(wǎng)絡(luò)熱詞里反復(fù)出現(xiàn)chkdsk /f /r無(wú)法處理RAW驅(qū)動(dòng)器的問(wèn)題還有人在 Windows 下格式化分區(qū)成 ext4 后試圖用 chkdsk 修復(fù)。這里必須說(shuō)清楚chkdsk是微軟為 FAT/NTFS 設(shè)計(jì)的檢查工具它認(rèn)不出 ext4 的魔數(shù)magic number 0xEF53只會(huì)把你整個(gè) ext4 分區(qū)當(dāng)作RAW未格式化。所以在 Windows 下誤操作chkdsk /f e:不僅修不了 ext4還有可能把分區(qū)表或引導(dǎo)扇區(qū)弄得更亂?？缥募到y(tǒng)排障請(qǐng)務(wù)必使用對(duì)應(yīng)文件系統(tǒng)的原生工具鏈ext4 就老老實(shí)實(shí)用 e2fsprogs 全家桶fsck.ext4、dumpe2fs、debugfs、tune2fs 這些。4. 修復(fù)實(shí)操用 debugfs 清理斷尾塊然后防患于未然4.1 修復(fù)方案選型為什么放棄在線修改走 debugfs 手動(dòng)清確認(rèn)問(wèn)題是斷尾導(dǎo)致的邏輯空間泄漏后修復(fù)方案其實(shí)有兩條路方案 A在線收縮和擴(kuò)展offline resize loop。把文件系統(tǒng)縮到比邏輯使用量還小再擴(kuò)回來(lái)強(qiáng)制觸發(fā)塊分配的重新平衡。但這個(gè)方法要求邏輯空間必須小于收縮目標(biāo)對(duì)根分區(qū)操作也麻煩而且在大文件系統(tǒng)上執(zhí)行時(shí)間不可控我沒(méi)采用。方案 B用 debugfs 手動(dòng)將斷尾塊從 bitmap 中標(biāo)記為空閑。這是操作性最強(qiáng)、影響面最小的方案。核心思路是這幾個(gè)步驟確認(rèn)哪些塊組存在斷尾塊。在 debugfs 中用testb確認(rèn)塊的分配狀態(tài)。對(duì)確認(rèn)已分配但無(wú)歸屬的塊執(zhí)行clrb清空分配標(biāo)記。需要強(qiáng)調(diào)的是這是對(duì)文件系統(tǒng)元數(shù)據(jù)的直接篡改操作前必須備份整盤或至少備份所有關(guān)鍵元數(shù)據(jù)區(qū)。我當(dāng)時(shí)的備份策略是# 備份文件系統(tǒng)頭信息和塊組描述符 dd if/dev/sda3 of/root/ext4_header_backup.img bs4096 count32768 # 備份塊組描述符通常是第一個(gè)塊組的前 1MB 左右但為保險(xiǎn)備份了 128M 元數(shù)據(jù)區(qū) dd if/dev/sda3 of/root/ext4_gdt_backup.img bs4096 count32768 skip04.2 定位斷尾塊一段有點(diǎn)土的掛載對(duì)比法如果不用 debugfs 寫復(fù)雜腳本定位斷尾塊還有一種土辦法把文件系統(tǒng)以ro方式掛載到一個(gè)空閑 loop 設(shè)備上再把塊 bitmap 導(dǎo)出來(lái)與文件實(shí)際所在塊集合做 diff。# 只讀掛載禁止任何寫操作 mount -o ro,loop /dev/sda3 /mnt/check # 列出所有文件的實(shí)際塊號(hào) find /mnt/check -type f -exec filefrag {} \; /tmp/file_fragments.txt 2/dev/nullfilefrag是 e2fsprogs 自帶的工具能列出每個(gè)文件占用的物理塊區(qū)間。把所有這些區(qū)間收集起來(lái)合并成一個(gè)實(shí)際使用塊集合再對(duì)比dumpe2fs導(dǎo)出的已分配塊集合差集就是斷尾塊。這個(gè)方法雖然慢大文件系統(tǒng)上要跑很久但它是無(wú)侵入式的不需要修改任何元數(shù)據(jù)非常適合排查階段。我的實(shí)際操作是寫了一段 Python 腳本調(diào)用filefrag獲取每個(gè)文件的物理塊范圍然后與dumpe2fs -b導(dǎo)出的塊 bitmap 做集合減法。最終鎖定了一個(gè)約 210GB 的連續(xù)斷尾塊區(qū)間集中在兩個(gè)相鄰的塊組里。這個(gè)區(qū)間對(duì)應(yīng)的 inode 明明不存在但塊 bitmap 一直標(biāo)記它們?yōu)檎加谩?.3 debugfs 清理步驟與驗(yàn)證有了明確的斷尾塊范圍后清理就簡(jiǎn)單了。進(jìn)入 debugfs對(duì)每一個(gè)斷尾塊執(zhí)行clrbdebugfs -w /dev/sda3交互模式下testb 89472000 # 如果輸出 Block 89472000 marked in use且我們確認(rèn)無(wú)歸屬就執(zhí)行 clrb 89472000block 號(hào)可以從filefrag的結(jié)果中推導(dǎo)也可以用腳本循環(huán)生成 debugfs 命令。我寫了一個(gè)批量清理腳本先生成一個(gè)包含所有clrb命令的文件再讓 debugfs 批量執(zhí)行python3 - EOF # 假設(shè)斷尾塊起始?jí)K號(hào) 89472000結(jié)束 91000000 with open(/tmp/debugfs_cmds.txt, w) as f: for blk in range(89472000, 91000000): f.write(fclrb {blk}\n) # 每 10000 塊寫一個(gè) sif 同步避免 debugfs 的懶寫問(wèn)題 if (blk - 89472000) % 10000 0: f.write(sif\n) f.write(sif\n) EOF debugfs -w -f /tmp/debugfs_cmds.txt /dev/sda3這里有個(gè)經(jīng)驗(yàn)點(diǎn)debugfs 的clrb修改的是內(nèi)存中的塊 bitmap 緩存必須用sif命令強(qiáng)制同步元數(shù)據(jù)到磁盤否則退出后修改可能丟失。清理完成后重新跑fsck.ext4 -fy做一次確認(rèn)性檢查這次它應(yīng)該能順利通過(guò)清理后的文件系統(tǒng)然后重新掛載df -h的使用率從 92% 降到了 61%和du的結(jié)果對(duì)上了。業(yè)務(wù)恢復(fù)正?？臻g憑空蒸發(fā)的問(wèn)題徹底解決。4.4 如何從根源上減少斷尾問(wèn)題delalloc 之外的保險(xiǎn)絲修復(fù)只是第一步更重要的怎么防再犯。斷尾問(wèn)題在正常運(yùn)行時(shí)幾乎不可能自我暴露但一旦碰上掉電、強(qiáng)制重啟、磁盤 IO 異常中斷風(fēng)險(xiǎn)就會(huì)成倍上升。我的建議是這套組合拳1. 高危場(chǎng)景關(guān)閉或降低 delalloc 的影響面。如果文件系統(tǒng)主要用于存數(shù)據(jù)庫(kù)、虛擬機(jī)鏡像這類對(duì)一致性要求極高的文件可以在mount參數(shù)中加nodelalloc或datajournal。代價(jià)是寫性能下降但換來(lái)的是寫路徑的一致性窗口更小。我自己的策略是日志類、臨時(shí)目錄用默認(rèn)的dataordereddelalloc核心數(shù)據(jù)目錄單獨(dú)掛載開啟nodelalloc。2. 定期做塊 bitmap 對(duì)賬。不用每月查但至少每季度要跑一次dumpe2fs和du的對(duì)賬腳本。差異超過(guò) 5% 就值得深挖。3. 監(jiān)控掉電事件并記錄。在/etc/sysctl.conf或 systemd 里配置斷電后的自動(dòng)檢查腳本可以在/etc/rc.local里加入# 檢測(cè)上次關(guān)機(jī)是否正常 if [ -f /var/lib/systemd/random-seed ]; then mount -o remount,ro / fsck.ext4 -fn /dev/sda3 /var/log/fsck_check.log 21 mount -o remount,rw / fi4. 有條件就上 LVM 快照副本兜底。文件的邏輯完整性和塊分配層的完整性是兩碼事。LVM 快照可以一定程度上減輕元數(shù)據(jù)損壞的爆炸半徑但要注意 LVM 快照本身也有 COW 塊泄漏的可能不是銀彈。5. 事后復(fù)盤這次故障教給我的三件事第一不要神話 fsck。它的名字聽著像文件系統(tǒng)修復(fù)瑞士軍刀但它能處理的只是元數(shù)據(jù)沖突?？臻g記賬的邏輯泄漏、斷尾塊、孤兒塊這類不違反結(jié)構(gòu)規(guī)則的廢話不在它的職責(zé)范圍。排障時(shí)要先擺正工具能力的邊界再思考現(xiàn)象背后的機(jī)制。第二延遲分配是性能與一致性的典型 trade-off。ext4 默認(rèn)開啟 delalloc 是正確的默認(rèn)值因?yàn)榻^大多數(shù)場(chǎng)景下它帶來(lái)的寫性能收益遠(yuǎn)大于一致性風(fēng)險(xiǎn)。但在關(guān)鍵業(yè)務(wù)系統(tǒng)上運(yùn)維人員必須清楚這些默認(rèn)值可能帶來(lái)什么隱患并主動(dòng)為不同 IO 模式設(shè)計(jì)不同的掛載策略。這次故障如果一開始就給數(shù)據(jù)分區(qū)關(guān)閉 delalloc大概率就不會(huì)發(fā)生。第三對(duì)賬是文件系統(tǒng)排障的第一手段。df 和 du 的差異、dumpe2fs 的 free blocks 與 df 的 avail 空間是否一致、文件系統(tǒng)層的統(tǒng)計(jì)與存儲(chǔ)陣列的 LUN 容量是否匹配——這些日常對(duì)賬看起來(lái)枯燥但往往能在故障發(fā)生前就暴露隱患。我這次是等磁盤滿了才被動(dòng)發(fā)現(xiàn)代價(jià)是業(yè)務(wù)中斷了將近兩個(gè)小時(shí)。最后分享一個(gè)小技巧如果你遇到類似情況又不敢直接在出問(wèn)題的設(shè)備上操作可以先把分區(qū) dd 成鏡像再用 loop 設(shè)備掛載排查或者把元數(shù)據(jù)區(qū)的備份拷貝一份。文件系統(tǒng)問(wèn)題上永遠(yuǎn)給自己的手抖留下后悔藥。