在Linux中存儲和訪問多達1000萬個文件

我正在編寫一個應用程序，需要存儲大量文件大約1000萬。在Linux中存儲和訪問多達1000萬個文件

它們目前以UUID命名，每個大小約爲4MB，但大小始終相同。從這些文件讀取和寫入將始終是順序的。

兩個主要問題，我尋求答案爲：

1）文件系統將是最適合這個。 XFS或ext4？ 2）是否有必要將文件存儲在子目錄下，以減少單個目錄中文件的數量？

對於問題2，我注意到人們試圖發現XFS可以存儲在單個目錄中的文件數量限制，但沒有發現超過數百萬的限制。他們注意到沒有性能問題。那麼在ext4下呢？

搜索人員做類似的事情時，有人建議將索引節點編號存儲爲文件的鏈接，而不是文件名以獲得性能（這是在我正在使用的數據庫索引中）。但是，我沒有看到一個可用的API來通過inode編號打開文件。這似乎更多的是改善ext3下的性能的建議，我不打算按照這種方式使用它。

什麼是ext4和XFS限制？從一個開始就有什麼性能優勢，並且您可以看到在我的情況下使用ext4超過XFS的原因？

來源

2011-02-16 Matt

參見例如http://lwn.net/Articles/400629/ – nos

你應該確定將文件存儲在子目錄中。

EXT4和XFS都使用文件名進行有效的查找方法，但是如果你需要在目錄如ls或find你會很高興有1,000管理的塊中的文件運行的工具 - 10,000個文件。

inode數字是爲了改善EXT文件系統的順序訪問性能。元數據存儲在inode中，如果您不按順序訪問這些inode，則元數據訪問將隨機化。通過以inode順序讀取文件，您也可以按順序訪問元數據。

來源

2011-02-16 18:35:57

隨着inode號碼的事情，我將如何通過inode打開文件？那麼我可以避免使用昂貴的統計操作嗎？ – Matt

@Matt無法通過inode打開文件（它會繞過Unix訪問控制方案的一部分）。但是'readdir'告訴你inode的號碼，所以你可以通過inode number對你的文件名列表進行排序，然後按順序打開它們。順便說一句，「'統計是昂貴的」是過於簡單化;更準確的說法是「stat（f）; open（f）'比」'h = open（f）; fstat（h）'「要貴一些。大小寫是* pathname processing *，而不是磁盤訪問。差異曾經是2倍，但是對於現代系統應該少得多。） – zwol

@Zack - 感謝非常有用的比較stat/open vs open/fstat – Matt

現代文件系統將允許您將1000萬個文件全部存儲在同一目錄中（如果您願意的話）。但工具（LS和它的朋友）將無法正常工作。

我建議放一個級別的目錄，一個固定的號碼，可能是1,000個目錄，並將文件放在那裏（10,000個文件可以容忍的shell和「ls」）。

我見過創建多級目錄的系統，這實際上是不必要的，增加了inode消耗，並使遍歷速度變慢。

10M文件不應該真的成爲一個問題，除非你需要對它們進行批量操作。

我希望你需要修剪舊文件，但像「tmpwatch」這樣的東西可能會適用於10M文件。

來源

2011-02-16 23:17:05 MarkR

謝謝，是mkdir一個緩慢的操作？我應該在啓動時預先製作目錄，然後假設它們存在嗎？ – Matt

關於目錄的好主意。它很薄你是對的 – Matt

一旦你進入同一個目錄中的數百萬個文件， ext4'開始掙扎並且獲得索引散列衝突。 – steve

在Linux中存儲和訪問多達1000萬個文件

回答

相關問題