ext3 fsck 時間與分區大小
我正在為大型儲存場進行設置，並且為了避免需要長達一個月的 fscks，我的計劃是將儲存拆分為許多較小的文件系統（這很好，因為我有一個儲存良好的文件樹, 所以我可以很容易地在
1/,2/,3/,等上安裝單獨的文件系統4/）。我的困難在於找到文件系統的“合理”大小的任何列舉，以保持 fsck 時間同樣“合理”。雖然我完全意識到給定大小的絕對時間將在很大程度上取決於硬體，但我似乎找不到任何關於具有不同文件系統大小的 ext3 fsck 時間的曲線形狀的描述，以及其他變數是什麼（單個目錄中的文件系統是否比一個目錄中的文件系統花費更長的時間，樹中數千個目錄中的每個目錄中有 10 個文件；大文件與小文件；完整文件系統與空文件系統；等等）。
有沒有人提到任何經過充分研究的數字？如果做不到這一點，關於這些問題的任何軼事至少應該有助於指導我自己的實驗，如果需要的話。
編輯：澄清：無論文件系統如何，如果元數據出現問題，都需要檢查。是否啟用或需要基於時間或掛載的 re-fscks 都不是問題，我要求專門針對 ext3 的數字的唯一原因是因為這是最有可能選擇的文件系統。如果您知道具有特別快的 fsck 程序的文件系統，我願意接受建議，但它確實需要是一個強大的選項（聲稱“文件系統 X 永遠不需要 fscking！”將被嘲笑和嘲笑） . 我也意識到備份的必要性，並且 fsck 的願望不能替代備份，但是只是丟棄文件系統並在出現故障時從備份中恢復，而不是 fscking 它，似乎真的，
根據Mathur 等人的論文。（第 29 頁），e2fsck 時間在某個點之後隨著文件系統上的 inode 數量線性增長。如果圖表是可以參考的，那麼使用多達 1000 萬個 inode 的文件系統會更有效。
切換到 ext4 會有所幫助 - 在您的文件系統未載入到邊緣的情況下，性能提升（由於未檢查標記為未使用的 inode）沒有明顯的影響。
我認為您將不得不進行自己的基準測試。Google上的快速搜尋沒有發現任何東西，除了 ext4 fscks 比 ext3 快很多。
因此，創建一些 ext3 分區，100GB、200GB 等，直至您將使用的磁碟大小。然後用數據填充它們。如果您可以使用類似於您的生產數據的數據（每個目錄的文件、文件大小分佈等），那將是最好的。請注意，簡單地從另一個分區或備份設備複製文件會將它們放置在完美佈局和碎片整理的磁碟上，因此您的測試將缺少大量的磁碟磁頭尋軌時間，這些時間將來自大量的寫入/修改/刪除。
您還需要考慮並行 fscks。查看 /etc/fstab 中的最後幾個欄位。同一物理磁碟上的分區應按順序進行；同一控制器上的多個磁碟可以並行完成，但請注意不要使控制器過載並減慢它們的速度。