《文件系統fsck提速方案》要點：
本文介紹了文件系統fsck提速方案，希望對您有用。如果有疑問，可以聯系我們。

朱穎航(個人微信號：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的新版內核為比較穩妥的解決方案.

文章出處：互聯網運維雜談

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4481.html