高目錄文件比對 XFS 的影響
我們正在建構一個可能會生成非常大的 XFS 卷的產品，並且我正在嘗試發現在給定架構的情況下我們可能會遇到的擴展瓶頸。
當我們操作文件時，它們會被放置到 XFS 卷上的目錄中。由於我們處理的文件數量眾多，文件數量肯定在幾千萬，並且在發布後不久可能會達到幾億。我們知道這一點是因為我們目前的產品就是這樣執行的，所以我們有理由期待我們的下一個產品也能做到這一點。
因此，正確的早期工程是有序的。
本周文件基於以下粗略佈局：
$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file這給出了看起來有點像的目錄：
0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file將 md5sum 分塊的原因是為了避免“一個目錄中的大堆文件/目錄”問題。由於 md5sum 分塊，這意味著 1 個文件會導致創建 8 個目錄。這具有非常明顯的 inode 影響，但我不清楚一旦我們擴大規模，這些影響將對 XFS 產生什麼影響。
有什麼影響？
順便說一句，這是核心 2.6.32，目前是 CentOS 6.2（如果需要，可以更改）。
在測試中，我使用預設值創建了 xfs 卷，並且沒有使用任何掛載選項。這是為了儘早解決問題。
noatime很簡單，因為我們不需要它。整體 XFS 調整是我需要解決的另一個問題，但現在我擔心我們現在設計的元數據乘數效應。我已經知道更好的解決方案是什麼，我只是不知道我是否有理由推動改變。
由於 md5sums 在前幾位上是非常獨特的，而且個別子項目很少超過 500 萬個文件，在我看來，我們只需要前兩個塊。這將產生如下佈局：
0123456/001/0e15/a644/897219acb4b597f651d69a4d/file完全完整的第一級和第二級將在每個第一級目錄中有 2 16 個第一級目錄和 2 16個二級目錄，卷上總共有 2 32 個目錄。
因此，假設的 500 萬文件子項目將有 2 16個一級目錄，每個目錄中大約有 76 (+/- 2) 個二級目錄，每個二級目錄中有一個或兩個三級目錄。
這種佈局的元數據效率要高得多。我只是不知道是否值得努力改變現在的情況。
除了 XFS應該擴展到此之外，沒有其他主要建議。我在 2003 年開始使用文件系統，因為我需要處理一個可以輕鬆在單個目錄中包含 800,000 個文件的應用程序。ext2 和 ext3 在這些文件系統中的操作通常會失敗。
這在很大程度上取決於您的應用程序以及它如何訪問文件（目錄遍歷等）。
如果這一切都在一台伺服器上，我會根據您對大量元數據操作的期望來查看外部 SSD 日誌。但你知道那部分。我仍然會使用第二個 md5 範例來推動重組。我的意思是，現在是重構的好時機，對吧？