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

Question

我正在編寫一個需要存儲大約1000萬個文件的應用程序。

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

我正在尋找2個主要問題的答案：

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

對於問題2，我注意到人們已經嘗試發現可以存儲在單個目錄中的文件數量的XFS限制，並且沒有找到超過數百萬的限制。 他們注意到沒有性能問題。 在ext4下怎么樣？

在人們做類似事情時，有些人建議將inode編號存儲為文件的鏈接而不是文件的性能（這是在數據庫索引中。我也在使用）。 但是，我沒有看到用於按inode編號打開文件的可用API。 這似乎更像是在ext3下提高性能的建議，我不打算順便使用它。

ext4和XFS限制是什么？ 從一個到另一個有什么性能優勢，你能看到在我的情況下使用ext4而不是XFS的理由嗎？

Answer 1

您絕對應該將文件存儲在子目錄中。

EXT4和XFS都使用高效的文件名查找方法，但是如果您需要在ls等目錄上運行工具或者find您將很高興將文件保存在1,000到10,000個文件的可管理塊中。

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

Answer 2

如果您願意，現代文件系統將允許您將1000萬個文件存儲在同一目錄中。 但工具（ls及其朋友）將無法正常工作。

我建議放一個級別的目錄，一個固定的數字，可能是1000個目錄，並將文件放在那里（10,000個文件可以容忍shell，“ls”）。

我已經看到了創建多級目錄的系統，這確實是不必要的，增加了inode消耗並使遍歷變慢。

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

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