我在这个主题上看到的最后一个真正的问题是大约两年前（ ext4准备好用于生产 ）。
在这段时间内， ext4又如何改进？
XFS ， JFS和ext3是备用的可靠select。 我只在最近的Ubuntutesting/开发环境中使用了ext4，并没有看到任何问题 – 但是它们也是低使用率的工作站，虚拟机和一次性的培训环境。
从速度和可靠性的angular度来看，ext4现在是如何堆积起来的，特别是XFS和JFS已经有了一些成熟的时间了。
ZFS是一个可行的select（看起来它是一个保险丝 模块 ，可能不适用于Linux）。
不幸的是，在Linux上，ZFS仍然不是一个可行的解决scheme，即使你忽略了作为FUSE模块的问题（这可能会严重影响某些工作负载的性能）。 它根本不够完整。 另外，我不认为在Linux上有一个ZFS debugging ，这是一个严重的负面影响。
debugfs是UNIX上低级文件系统修复工具的传统名称。 e2fsprogs包含一个用于Ext2 / 3/4，XFS工具包含xfs_db等。 其他文件系统，尤其是像FFS和JFS这样的较长时间的文件系统也有这样的工具。 它基本上是一个工具，使您可以读取和操作音量较低的数据， 特别是在恢复过程中非常有用。
至于ext4，我怀疑它在生产中是相当实用的，但我build议实际上模拟你的工作量。 在各种不同的应用程序中警惕各种不安全的代码path，这些path会根据ext4的设置破坏数据（请注意，AFAIK这些问题也可能发生在XFS和JFS中）。
XFS仍然是一个好的，稳定的解决scheme，但是我承认由于XFS的创build/取消链接性能不佳，我从XFS移到了ext4。 如果你没有很多不断创build和删除的小文件，这仍然是一个很好的select。 networking上的大多数基准都可以使用硬编码。 放缓与XFS的特定优化有关，导致某些日志操作相当缓慢（创build/取消链接）。 尽pipe如此，它在元数据访问和读/写方面速度非常快。 大文件，恕我直言（多媒体编辑？）的好select。
还没有真正testing过JFS，但是我听到相当好的意见 – 只要先检查是否有可以可靠使用的debugfs工具。
Linux上的ZFS现在可以在本地级别上运行：
ZFS包含许多用于确保文件系统完整性的系统，其中最关键的是zpool scrub，它对每个文件进行校验和检查和重build（如果需要）。
对于今天的生产系统，我不会在Linux上使用ZFS。 但是，如果在几年内必须存储40 TB以上的数据，那么ZFS就是我要去的地方。