我的问题是关于 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）的问题。