Linux文件系统

Question

最近我们的存储出现故障，我们需要 fsck。存储大约1.2 Tera，我们花了5个多小时。

ext3 文件系统是否有替代解决方案，或者比 ext3 更好的解决方案？欢迎提出正反两方面的建议。

TQVM

Answer 1

有一些 LWN 文章可能会引起您的兴趣：

• fsck 的多种面孔
• 文件系统：chunkfs 和 reiser4
• chunkfs 发生了什么？

Answer 2

你在这里有很多选择。文件系统虽然具有类似的基本用途，但它们的行为都不同，具体取决于您投入的工作负载类型——实际上可以肯定的是，虽然有人可能会发誓说 ReiserFS 的好处，但另一个人会厌恶它。

从企业的角度来看，我最熟悉的两个文件系统是 JFS 和 XFS。虽然使用不是很广泛，但我是 JFS 的粉丝，因为它永远不会让我失望，在各种工作负载中表现良好，非常稳定，并且对电源故障的容忍度相对较高。XFS 会为您提供更好的性能，但如果电源中断，它确实具有显着的已知数据丢失或损坏风险 - 如果您管理电源，绝对值得使用。

桌面领域 我现在只使用 Ext4，因为它比 ext3 快得多，并且导致更少的 I/O 开销和 CPU 使用，这对于延长我的笔记本电脑电池寿命非常有用:-)

有关更多信息的良好参考：http : //en.wikipedia.org/wiki/Comparison_of_file_systems

编辑：正如其他人也提到的，如果出现文件系统错误 [损坏等]，必须进行某种修复才能解决问题。无论这是自动的 [如 ZFS] 还是手动的 [几乎所有其他东西]，您的文件系统都需要时间才能恢复到干净的状态。大多数情况下，您将不得不对未挂载或处于只读状态的文件系统执行这些操作。这需要多长时间主要取决于问题的严重程度、元数据的大小/状态和磁盘速度。我经历过的一个可怕的时间示例是 XFS 损坏需要完整的 12TB 文件系统重建，这需要大约 12 小时才能完成。

Answer 3

我怀疑当您必须对文件系统进行全面检查时，对于任何文件系统，您都会看到类似的结果。如果您有 1,000,000 个 inode 正在使用，那么如果您必须检查所有 inode 的一致性，它们的组织方式实际上并不重要。不管你怎么剪，你都会接触到 1,000,000 个文件。

可以显着加快速度的是更快的磁盘和更多的主轴。如果您需要 1.2 TB，与使用单个 1.2 TB SATA 驱动器相比，RAID 10 中的 8 个 300 GB SAS 驱动器的性能要好得多，与文件系统无关。当然，它会花费你更多，但是你的停机时间会给你带来什么损失？它仍然不会阻止文件系统错误，但会减少恢复时间。

还需要考虑的是故障卷上的数据是否变化很大。如果它大部分是静态的并且您有一个良好的备份，则重新mkfs卷并从备份中恢复可能会更快。您可能会丢失最近的更改，但同样，您必须权衡这与停机成本。