EXT4 單個較大卷或許多較小卷
我的問題是關於 EXT4 卷相對於大小的文件系統性能。我們有一個執行任意 Linux 平台的 NAS。NAS 在帶有 LVM 的硬體 RAID 6 中具有 (12) 個 4TB 磁碟，從而產生大約 40 TB 的可用儲存空間。NAS 是一個文件伺服器（netatalk 和 samba）。隨著儲存空間的耗盡，我們將連接 SAS 被動擴展單元。
我的問題：
- 為了獲得最佳性能，我們是否最適合從單個 40 TB 單片 DATA 卷開始並不斷增長？還是我們會更好地創建許多更小的數據卷？
- 問題 1 的答案有多少取決於文件系統類型、使用情況等。
- 是否有計算最佳卷大小的最佳實踐或規則？
我的偏執狂因多年的經驗而傷痕累累，不相信最近的改進，不喜歡使用單個大型 EXT4 卷來提供聽起來像非結構化文件服務的想法。EXT4 對於最近核心中的任務可能已經足夠了，但它仍然聞起來像 EXT 文件系統。那些故障模式不好，而且……我不相信他們。
多年來，如果可能的話，我會選擇xfs，因為它是為大規模設計的，最近的改進已經解決了它過去眾所周知的許多 inode 性能問題（顯然我相信我喜歡的文件系統的改進）。它不 fsck，甚至聲稱需要它。這很好，因為 fscking 一個 40TB EXT4 卷需要很長時間，而這段時間是計入停機時間預算的。
不過， zfs或btrfs是未來的發展方向。儘管 btrfs 確實接近於贏得這一榮譽，但核心中的支持還沒有完全企業化（或許可）。如果您願意處理可能還沒有防彈的新事物，那麼防彈應該會出現在未來的核心更新中，您不必處理更改文件系統的問題。此外，對於這些，“多卷”的概念並不完全適用，因為 FS 本身會創建子卷。
最佳體積大小
對於“非結構化文件服務”，您的縮放因子可能是您的目錄有多大。從前，一個目錄中的 64K 文件/子目錄在 EXT 文件系統上非常糟糕，但這已得到修復。同時，系統中的 inode 數量可能會帶來很大的擴展問題（800 萬個文件，在某些文件系統上效果不佳）。
到目前為止，其中大部分已經被設計好了。即使是我不太喜歡的 ext4，也可以處理數十億個文件。會很快嗎？嗯，看你存的是什麼。
備份/恢復注意事項
沒有人真正想到的事情。你在做什麼？您是僅依賴 LVM 快照和 RAID，以某種方式導出完整副本（tar 到磁帶），還是通過 rsync 或其他方式定期同步到遠端系統？您正在做的事情將影響您的文件系統選擇。
XFS 為您提供 xfsdump，它是一個非常好的備份 XFS 文件系統的實用程序。這比直接將 fs 結構儲存在存檔中更好更快
tar，因為 tar 必須建構 posix 抽象來減慢它的速度。在磁性介質上，基於範圍的文件系統在備份方面做得更好，因為它們更擅長避免碎片。Xfsdump 繞過了一些碎片問題，因為它是本機工具。通常，inode 性能將成為 touch-all-the-files 備份樣式（tar 和 rsync）的問題。