最近我们的存储出现故障，需要进行 fsck。存储量约为 1.2 Tera，我们花了 5 个多小时才搞定。
有没有 ext3 文件系统的替代解决方案，或者比 ext3 更好的解决方案？欢迎提出优缺点的建议。
直立式真空泵
答案1
有一些 LWN 文章可能会引起您的兴趣：
答案2
我怀疑，当您必须对文件系统进行全面检查时，您将看到任何文件系统的类似结果。如果您正在使用 1,000,000 个 inode，那么如果您必须检查所有 inode 的一致性，那么它们的组织方式实际上并不重要。无论如何，您都将接触 1,000,000 个文件。
速度更快的磁盘和更多的主轴可以显著加快速度。如果您需要 1.2 TB，那么 RAID 10 中的 8 个 300 GB SAS 驱动器的性能将明显优于单个 1.2 TB SATA 驱动器，与文件系统无关。当然，这会花费您更多钱，但停机时间会给您带来什么损失？它仍然无法防止文件系统错误，但可以缩短恢复时间。
还需要考虑的是故障卷上的数据是否变化很大。如果数据基本是静态的，并且您有良好的备份，则重新安装mkfs卷并从备份中恢复可能会更快。您可能会丢失最近的更改，但同样，您必须权衡这一点与停机成本。
答案3
这里有很多选择。文件系统虽然具有类似的基本用途，但根据您向其投入的工作负载类型，它们的行为方式各不相同 - 几乎可以肯定的是，虽然一个人可能坚信 ReiserFS 的好处，但另一个人会讨厌它。
从企业的角度来看，我最熟悉的两个文件系统是 JFS 和 XFS。虽然使用得并不广泛，但我还是 JFS 的粉丝，因为它从未让我失望，在各种工作负载下都能获得良好甚至高性能，非常稳定，并且相对而言对电源故障具有耐受性。XFS 的性能稍好一些，但如果电源中断，它确实存在数据丢失或损坏的重大已知风险 - 如果您有管理电源，绝对值得使用。
桌面领域我现在专门使用 Ext4，因为它比 ext3 快得多，并且 I/O 开销和 CPU 使用率更低，这对延长我的笔记本电脑电池寿命非常有帮助 :-)
更多信息的良好参考： http://en.wikipedia.org/wiki/Comparison_of_file_systems
编辑：正如其他人也提到的那样，如果发生文件系统错误 [损坏等]，则必须进行某种修复才能解决问题。无论是自动 [如 ZFS] 还是手动 [几乎所有其他操作]，文件系统都需要时间才能恢复到干净状态。大多数情况下，您必须在文件系统未挂载或处于只读状态的情况下执行这些操作。这需要多少时间主要取决于问题的严重性、元数据的大小/状态以及磁盘的速度。我经历过的一个非常耗时的例子是 XFS 损坏，需要重建完整的 12TB 文件系统，大约需要 12 小时才能完成。
答案4
如果您使用的是 Linux，我实际上建议您仔细研究一下 btrfs。
我认为目前 Linux 中没有适合大容量存储的文件系统。XFS、JFS reiser 和其他文件系统本身就存在一系列问题。例如，JFS 的 defrag 尚未移植到 Linux。只有当您能够确保永远不会断电并且您的硬件绝对可靠时，XFS 才是一个不错的选择。我不相信后者是可预测的。遗憾的是，Reiser 已经不再处于积极开发阶段，并且有相当多的 bug。
btrfs 旨在将类似 ZFS 的功能引入 Linux，同时避免 ZFS 的一些设计缺陷。但请记住，btrfs 目前仍在积极开发中，但它正在日趋成熟。我目前不建议将其用于生产，但它可能是您未来可行的升级途径。在等待期间，您可能实际上想继续使用 ext3/4。虽然它们远非完美，但在我看来，它们是您目前在 Linux 上的最佳选择。