FS 用於許多小文件，主要是讀取？
我需要一個方向，因為所有的部落格/長凳似乎都相互矛盾。
目標：
在 FS 上以類似於 AB/CD/EF 的目錄樹方式有很多小文件… 兩個大小組：G1：10-20 kB G2：100-500kB
我需要非常快速地訪問使用 nginx 為它們提供服務。
受限
刪除或創建性能並不重要。極端情況下，這可能需要一分鐘，我不在乎。讀取/訪問必須快速 <->nginx。文件在創建時被複製到不同的磁碟，因此不涉及突襲。只是商品。動態 inode 創建或類似的。可靠性不是主要問題，因為在 3 個不同的伺服器上有重複。
背景與矛盾
我讀過 XFS 適合包含許多小文件的高性能郵件伺服器。其他人說 XFS 在處理小文件方面很糟糕，而 EXT4 更好。
它在整個網際網路上一直相互矛盾。
問題
總的來說，問題在於 inode 分配。大 inode 表浪費空間。將其設置得太弱，您就注定要失敗：擦除並重新創建分區（不可能發生）。
對我來說，這是一個陷阱，即使空間仍然可用，它也會阻止我添加新文件。這就是為什麼我希望切換到其他東西。
而且由於那裡的高度動態性和不可預測的文件數量，我似乎陷入了困境。因此需要您的意見。
btrfs 被認為還沒有準備好生產。其他人似乎出局（可靠性）
在這種情況下我應該使用什麼FS？
它在整個網際網路上一直相互矛盾。
但是您希望在這裡得到一致的答案嗎？
我要提出的唯一具體建議是忘記 ZFS - 除非您在 Solaris 上執行（這很有意義）。
除此之外，您如何配置磁碟、I/O 調度程序以及為磁碟 I/O 提供備用記憶體比選擇 FS 重要得多——但您確實特別詢問了 FS。但是，您沒有提供很多有關您的彈性要求的資訊：您的電源有多可靠？您需要快照功能嗎？
雖然我是 Reiser 的忠實粉絲，並且多年來一直在我的網路伺服器上執行它，但我不會在新系統上使用它——它從未被用作 Linux 核心的一部分，而且開發正在逐漸減少。
因此，在 Linux 機器上，剩下的候選者是 XFS、JFS、Ext4 和 BTRFS（也有 NILFS——但這又是一個小眾工具，恕我直言，性能方面又很差）。
如果您必須使用 LVM（即使沒有快照 IME 也會有很大的性能成本），那麼請確保您有一個支持屏障的最新版本 - 如果您使用的是日誌文件系統，請啟用屏障。
如果性能是您唯一考慮的因素，那麼是時候開始進行基準測試了——我建議使用 Jens Axboe 的 fio 來測量讀/寫性能——它可以配置為模擬許多工作負載。