朱穎航（個人微訊號：casualfisher），北京靈犀智造科技有限公司（www.linkedsee.com）技術總監，設計參與了百度智慧資料中心專案，集中在智慧供電方向， 負責了硬體感知專案，參與設計伺服器硬體採集及管理工具， 並基於採集資料進行故障及使用趨勢預測，曾設計和開發重複資料刪除檔案系統， 參與多個儲存相關的開源專案(mhvtl, zfs on linux等)

在分散式檔案系統（例如HDFS）中，當出現異常掉電、加電恢復後，通常儲存系統會檢測內部資料的一致性，檢測分為兩個層次

• 首先是單機檔案系統的資料一致性檢查
• 其次是使用了erasure coding編碼的儲存系統進行資料一致性校驗

必要時進行根據erasure coding進行資料恢復。

根據阿姆達爾定律，儲存系統恢復的整體時間由序列部分最慢的節點決定。

在 ec 恢復的過程中，通常是多個節點，多個裝置之間並行恢復，系統的瓶頸通常受限於第一階段本地檔案系統的 fsck 過程。

在類 HDFS 中，通常使用 SATA 硬碟儲存資料，SATA 硬碟的磁碟容量隨著新的SMR、HAMR技術的出現而越來越大，而傳輸的速率目前受限於 SATA3.0定義的最大速率（6Gb/s，實際使用中通常順序讀穩定在 100-150MB/s 之間），因此提升檔案系統的fsck速度就顯得愈發重要，本文中以 ext4 檔案系統為例，列舉除了檔案系統 fsck 提速的若干方案。

方法1：優化檔案系統及 fsck 本身

Ted 在 e2fsprogs版本1.41.9中已經完成了針對 ext4 的 fsck 優化工作，而公司目前線上的 fsck 版本為 1.41.12 ，已經加入了這個優化。

從優化fs check本身考慮，《ffsck: The Fast File System Checker》中提出了對於ext3磁碟資料格式進行修改，在每個block group內部加入專為元資料儲存的空間，以優化fsck中磁碟對於元資料的隨機定址(e2fsck中 phase1/掃描檔案間接索引佔據了總時間的90%以上)，進而提高效能，由於需要修改磁碟上資料儲存的格式，所以此方法不可行。

思路：

建議如果需要優化fscheck本身，下一步可以考慮和應用型別結合起來進行（例如找到應用關心的檔案進行檢查，不關心的直接跳過，對於hadoop hdfs之類的資料儲存，目錄和檔案均有用，因此此方法不適合），並且在mkfs的時候，使用bigalloc和inline data的功能，大檔案保證其連續性，減少元資料儲存量，小檔案可以直接合併入 inode，減少 seek 的程度，不過這種方案並未從根本上解決問題，隨著檔案系統碎片的增加，可能抵消掉帶來的效能提升。

方法2: online fsck

ZFS，BTRFS 等由於採用了 COW 機制，對寫入磁碟的資料不會再進行修改，保證存檔資料的穩定性，在恢復之後可以立即對外提供服務，將對斷電時刻的資料檢查作為一個優先順序較低的操作（ZFS為scrub操作），可以和檔案系統的正常操作並行執行，一旦有正常的讀寫等操作，將會停止 fsck 過程，減少對於應用效能的影響。

由於資料庫等系統需要儘可能的線上提供服務，所以我們希望能夠儘可能的縮短宕機後的啟動時間。所以，如果可以實現 online fsck 的功能，則可以儘可能的縮短系統啟動的時間，同時保證檔案系統不被破壞。

目前已知的可以進行online fsck的檔案系統是 zfs, ffs, btrfs。

Ted 給出的建議是可以考慮在分配磁碟塊的時候在相應的 block group 上新增相應的標記，表明這個block group 正在進行磁碟塊的分配，在出現宕機後，這個 block group 的資料只進行讀操作，所有寫操作都會被對映到其他的 block group中。這樣可以儘可能的保證檔案系統的一致性（來自ext4 workshop總結）。

鑑於kernel mainline已經明確表明不會接受ext4 snapshot的 patch，所以基於 fs 的 snapshot 進行 online fsck無法進行，可以嘗試結合比較成熟的 lvm 快照為 fsck 提速。

Andreas的回覆： *

When you write about online e2fsck, what do you mean exactly?  It is already possible

with LVM to create a read-only snapshot of a device and run read-only e2fsck. This

works because the LVM snapshot is hooked to ext4 to freeze the filesystem and flush

the journal before the snapshot is done.

Ext4 snapshots vs lvm snapshots

*

如何在已有的分割槽上建立lvm卷組

思路：

遇到宕機/掉電導致的 fsck 時間過長時，將已有的分割槽轉換為 lvm 分割槽，然後在lvm快照的基礎上進行 online fsck，此時檔案系統可以掛載供應用讀取（讀寫未出錯的檔案）。 優勢：從根本上免除了 fsck 帶來帶來的時延。

劣勢/待解決問題

• fsck 完成後如何清除 lvm 返回到raw partition的狀態
• 是否可以控制不使用第二塊盤進行重定向(提前保留部分空間)
• 瞭解到目前這種lvm online fsck啟動後會對應用的效能產生較大的影響，因此建議使用檔案系統內建的online fsck功能。

方法3：跳過fsck步驟

google 內部使用 ext4 時採用了no journal的掛載選項，說明在宕機、斷電過程後並不進行 fsck，而是通過上層應用對於資料的冗餘保證資料的一致性。

思路：

如果上層是 HDFS 之類的分散式檔案系統，可以考慮這種思路，但需要注意到副本在同一個機房內，機房斷電的情況。

針對以上的思路涉及如下實驗驗證：

測試：

測試環境：ST4000NM0053-1C1 2TB的硬碟+hadoop hdfs 寫入 1.3TB 資料（共個 38949 檔案，331 個目錄）

• 測試1：核心版本 3.10.16 (支援bigalloc+inline_data)+打了 bigalloc 支援補丁的 e2fsprogs 測試(fsck工具不支援inline_data，會 crash)，mkfs 選項：mke2fs -m 0 -C 1MB -I 4096 -O bigalloc $device
• 測試2： 2.6.32核心+ e2fsprogs 工具(版本 1.41.12 )mkfs選項：mkfs.ext4 -F -m 0 -b 4096 -Tlargefile （實際環境中 mkfs 選項）,測試中fsck引數均為-f -y

結果：測試1 fsck 3次平均時間12s。測試2 fsck 3次平均時間40s。

從測試結果可見，如果不能使用方法3中上層遮蔽fsck或者方法2中使用lvm及COW檔案系統的情況下，切換到使用了bigalloc和inline data的新版核心為比較穩妥的解決方案。

文章出處：網際網路運維雜談