我的问题是关于EXT4卷相对于大小的文件系统性能。 我们有一个运行任何Linux平台的NAS。 NAS在具有LVM的硬件RAID 6中具有（12）4TB磁盘，导致大约40TB的可用存储容量。 NAS是一个文件服务器（netatalk和samba）。 随着存储器耗尽，我们将连接SAS无源扩展单元。
我的问题：
在我这个偏执的人中，由于多年的经验和不信任最近的改进，不喜欢像非结构化文件服务那样的单个大型EXT4卷。 EXT4对于最近的内核来说可能是足够好的了，但是它仍然像EXT文件系统一样。 与那些失败模式是不好的…我不相信他们。
多年来，如果可能的话，我会尽可能地使用xfs ，因为它是为大规模devise的，最近的改进已经解决了很多以前知道的inode性能问题（显然，我相信我喜欢的文件系统的改进）。 它不fsck，甚至声称需要它。 这很好，因为fT的40TB EXT4卷将需要很长时间，这是停机时间的预算。
虽然zfs或btrfs是未来的方式。 内核支持并不完全是企业（或许可），虽然btrfs真的是接近获得这个荣誉。 如果你愿意处理可能还没有防弹的新function，那么在未来的内核更新中将会出现防范措施，你将不必处理改变你的文件系统。 另外，这些“多卷”的概念并不完全适用，因为FS本身就是创build子卷。
最佳音量大小
对于“非结构化文件服务”，您的缩放因素可能是您的目录有多大。 一次又一次，目录中的64K文件/子目录在EXT文件系统上非常糟糕，但是这个问题已经解决了。 同时，系统中的inode数量可能会产生很大的缩放问题（800万个文件，在某些文件系统上效果不佳）。
到目前为止，这些工作大部分都是devise的。 即使是我不特别喜欢的ext4，也可以处理数以百万计的文件。 会快吗？ 呃，取决于你正在保存的是什么。
备份/恢复注意事项
没有人真正想到的东西。 你在做什么？ 你只依靠LVM快照和RAID，以某种方式导出完整副本（焦油到磁带），或通过rsync或其他方式定期同步到远程系统？ 你在做什么会影响你的文件系统的select。
XFS为您提供了xfsdump，这是一个非常好的备份XFS文件系统的工具。 这比tar更好更快，因为它将fs结构直接存储在归档中，tar必须构buildposix抽象，从而减慢速度。
在磁性媒体上，基于扩展区的文件系统在备份方面做得好一些，因为它们更好地避免了碎片化。 由于是原生工具，Xfsdump绕过了一些碎片问题。 通常，inode性能将成为备份（tar和rsync）的全触摸文件样式的一个问题。