我的问题是关于 EXT4 卷相对于大小的文件系统性能。我们有一个运行任意 Linux 平台的 NAS。NAS 有 (12) 个 4TB 磁盘，采用硬件 RAID 6 和 LVM，因此可用存储空间约为 40 TB。NAS 是一个文件服务器（netatalk 和 samba）。当存储空间耗尽时，我们将连接 SAS 被动扩展单元。
我的问题：
- 为了获得最佳性能，我们是否最好从单个 40 TB 单片数据卷开始并不断增大它？还是创建许多较小的数据卷会更好？
- 问题 1 的答案在多大程度上取决于文件系统类型、用途等。
- 是否有任何计算最佳卷大小的最佳实践或规则？
答案1
我内心有些偏执，多年经验的伤痕和对最近改进的不信任让我不喜欢使用单个大型 EXT4 卷来提供非结构化文件服务的想法。EXT4 可能足以胜任最近内核中的任务，但它仍然像 EXT 文件系统。这些文件系统的故障模式并不好，而且...我不信任它们。
多年来我一直追求軟體系尽可能地，因为它是为大规模设计的，最近的改进已经修复了过去已知的许多 inode 性能问题（显然我相信我喜欢的文件系统的改进）。而且它不需要 fsck，甚至声称不需要它。这很好，因为 fsck 40TB EXT4 卷需要非常很长时间，而且这段时间是计入停机预算的。
文件系统或者文件系统是未来的发展方向。目前内核尚未完全支持（或许可），但 btrfs 确实接近获得这一殊荣。如果您愿意处理可能尚未防弹的新功能，防弹功能应该会在未来的内核更新中出现，您不必更改文件系统。此外，对于这些，“多个卷”的概念并不完全适用，因为 FS 本身会创建子卷。
最佳卷大小
对于“非结构化文件服务”，您的扩展因素可能是目录的大小。曾几何时，目录中的 64K 文件/子目录在 EXT 文件系统上非常糟糕，但这个问题已经得到解决。同时，系统中的 inode 数量可能会带来很大的扩展问题（800 万个文件，在某些文件系统上效果不佳）。
现在，其中大多数都已经设计好了。即使是我不太喜欢的 ext4，也可以处理数千万个文件。它会很快吗？嗯，取决于你保存的是什么。
备份/恢复注意事项
没人真正考虑过这件事。你为此做了什么？你只是依赖 LVM 快照和 RAID，以某种方式导出完整副本（tar 到磁带），还是通过 rsync 等定期同步到远程系统？你所做的将影响你的文件系统选择。
XFS 为您提供了 xfsdump，它是一款非常好的备份 XFS 文件系统的实用程序。它比 tar 更好更快，tar因为它直接将 fs 结构存储在存档中，而 tar 必须构建 posix 抽象，这会降低其速度。
在磁性介质上，基于扩展区的文件系统在备份方面表现更好，因为它们更善于避免碎片化。Xfsdump 凭借其原生工具绕过了一些碎片化问题。通常，对于触及所有文件类型的备份（tar 和 rsync），inode 性能将是一个问题。