當我們談到上述文件系統的優點和缺點時，最大的問題在于，文件系統的大小限制和如今存儲設備的容量相比，實在是小得讓人難以置信。

　　使用容量為3TB的硬盤，ext3/4文件系統最大可支持5塊硬盤，我們認為很少有人會買5塊容量為3TB的硬盤放進PC，XFS最大可以支持33塊3TB硬盤，即使如此，在我們看來還是太小了。顯然，文件系統支持的大小沒有隨硬盤容量，或大數據需求增長而擴容。我有一個家用NAS設備，帶有6塊硬盤，幸好我沒有買帶有8塊硬盤的NAS，因為XFS不支持我的NAS廠商，我想超過ext3文件系統的大小限制，必須創建多個文件系統。

文件系統模型的兩個問題

　　可能有些人會提出質疑，讓我提前預演你們的問題并給予解答。第一個可能的問題是“為什么你們需要這么臭的支持，下載下去自己調試不就成了嗎?大家都懂的”，這可能是真的，但事實是，它與我們無關 — 它與目前業務的市場現實有關(記住，我們都是Linux的支持者，每周都會寫有關Linux和存儲的系列文章)。

　　第二個可能的應答是“你們很愚蠢，不應該要那么大的文件系統”，你告訴我們不想要這些大文件系統的原因是，因為它們不能擴展，但我們需要它們，并且我們的客戶也需要它們，當支持8塊硬盤的NAS必須分解成多個文件系統時，我想我們的文件系統發展和支持模式已經被打破了。

　　我們做了一些檢查，最后認為有兩個問題：

　　1、在當前的文件系統模型中，列舉文件系統存儲的大量文件時存在元數據擴展問題，雖然XFS可支持到100TB，但我們看到，在存儲大量文件時，性能下降得非常利害，特別是當元數據變得支離破碎時。

　　2、這些文件系統增長已經接近它們的極限，性能表現似乎沒有和容量呈線性增長，反而隨碎片增多下降了。

　　我們決定研究一下第一個問題，因為沒有可擴展元數據，我們認為，持續的大數據塊性能并不重要，我一直是fsck的巨大支持者，部分廠商過去曾表示，所有你必須做的是檢查日志，你永遠都不需要驗證文件系統。

　　但這完全沒用，我們都遇到過無數的硬件問題，但我們從來沒有見過一個運行的文件系統可以從一個RAID恢復。這是POSIX文件系統的本性，事實上，只有元數據有日志記錄，鑒于性能影響，數據沒有日志記錄。我們推斷，Linux限制文件系統大小的一個主要原因是，在發生硬件事件后，它運行一次fsck所花的時間長短，在系統崩潰后，它要運行fsck檢查元數據(如超級塊，inode，范圍和目錄)，特別是存儲發生硬件事件后做這個檢查是極其重要的。

　　海量存儲測試很有必要

　　我們認為，如果有人真的使用50TB或100TB存儲，在文件系統中每個目錄放入多個文件，總量達5000萬-1億個文件(甚至10個文件)，測試ext4和xfs文件系統，他一定是個了不起的人，我們認為這個想法非常棒，但截至目前還沒有人做過這個測試。到處宣傳，希望有人實現這個瘋狂的想法。

　　我們都認為大文件系統的問題在于元數據掃描速度，假設你的文件系統中有1億個文件，文件系統的掃描速度是每秒5000個inode，如果遇到系統崩潰，fsck需要花20000秒或大約5.5小時，如果你是一家企業，你需要花一大半工作日等待fsck結束，這是不可接受的?，F在，鑒于網絡速度和系統處理能力的提升，包含1億文件的文件系統可能不會花那么多時間，單個文件服務器可以支持100用戶，每用戶100萬文件，這個數字夠大，但還不夠瘋狂。另一個問題是，我們不知道包含大量文件的大文件系統的掃描速度，如果這個數字不是5000而是2000會怎么樣?使用企業級3.5英寸硬盤，每塊硬盤的IOPS介于75-150，20塊硬件將可以實現至少1500 IOPS，問題是對兩個文件系統使用fsck可以實現的硬件帶寬百分比有多大?這就是我們要調查的。

　　最后一個意見：我們聽起來可能很悲觀，但我們知道Red Hat開發人員，如Dave Chinner和Eric Sandeen，一直在努力改善XFS的元數據性能，這些測試的目標之一是，看看他們所做的努力是否改善了fsck性能，是否值得企業生產系統采納。

　　原文出處：http://www.enterprisestorageforum.com/storage-hardware/the-state-of-file-systems-technology-problem-statement.html

　　原文名：The State of File Systems Technology, Problem Statement

　　作者：Henry Newman