我一直在遇到一些电力问题，其中大部分是突然停电几个月的电力，尽pipeups大部分都是解决问题的。
但是我仍然担心文件系统损坏，数据丢失。
当计算机closures，崩溃或其他文件系统问题时，xfs比ext3更差或者更不可靠？
有一个ups和一个好的备份策略（我有一个1,5 TB的磁盘，我想用来备份所有的关键数据）就够了，我不应该担心？
当电源closures时，我一直在阅读这个xfs zero out数据（虽然我认为这已经解决了），像XFS这样的东西对于数据损坏是不安全的。
启用写屏障并正确调整xfs，并进行ups和备份，可能是像ext3一样可靠的xfs，或者至less可以接受？
如果我使用/和/ home的xfs来获得更多的性能（主要是大文件），那么我会比使用xfs更多地使用我的数据。
没有人能比你自己更好地回答这个问题。
换句话说，testing它。
这并不难：做一台典型的机器，使其执行类似的任务（在我的情况下，是在两个SAN卷之间复制小文件）。 并在重负荷下，使其失败。 尝试每一个失败，你可以想像（在我的情况下，主要是关于拉一个卷，另一方面，在服务器和SAN交换机上的插件）。
所有候选文件系统在我的情况下重复ext3，XFS，ReiserFS和JFS。 现在我会做ext4和btrfs而不是ReiserFS和JFS。
我发现ext3在每百万中损失了大约5-10个文件，XFS大约在百万分之5-30之间，Reiser和JFS至less在一个案例中损失了几百，一千个文件。
所以在我的testing用例中，是的：ext3是最有弹性的文件系统，但XFS并没有我所害怕的那么大。 考虑到我接近ext3 8TB的限制，明确的答案是XFS。
我打算用慢节假日来重复更现代的文件系统; 我对ext4抱有很高的期望，但是直到我看到真正的失败之后，我的数据才会下注。 btrfs将会是一个有趣的testing，但是它还不够成熟。
我个人对XFS的经验是fsck不如ext3。 我们在XFS上运行了我们的镜像服务器，大约有3TB的空间用于Linux发行版以及我们镜像的类似内容。 有一点它有一些问题（我们没有电力故障，IIRC它刚刚开始报告错误）。 所以在重新启动时，它想做一个fsck。 但是，fsck占用的RAM比我们在系统上的2GB多，所以它开始交换。 3天后，内存耗尽。 我把盒子放到了3GB，然后就可以很快地完成fsck了。 我知道现在3GB的内存不多，但当时那是一个相当大的盒子。
我也试了一下我的笔记本电脑上的XFS。 这更像是你的“电源故障”情况，因为我的笔记本电脑出现了问题，所以我不得不频繁地重启电源。 我遇到了几个我曾经在崩溃前处理过的文件会恢复到几个小时前的拷贝的情况。 我编辑一个文件并在工作时多次保存，然后系统将locking，我会回到几个小时之前。
由于这些问题，我倾向于避免XFS。 看起来XFS fsck并不像EXT那样成熟，可能是因为XFS几乎不需要fsck，但是ext2 / 3/4经常这样做。
但是，我承认这些经验大概是5年前的事了。 希望他们现在好些了。 只是觉得我会传递我的经验。
回想起来，我意识到当时的EXT3也有腐败问题。 但是现在我运行了数以百计的基于EXT3的服务器，并且无法记住硬盘上一次造成损坏的时间。
真的，在XFS上真正让我感到厌烦的是fsck花费了太多的内存和系统冲击。 在我们的镜像服务器的情况下，它可以负担得起。 如果这是一个业务服务器，知道fsck将需要一段时间，但不是几天将是至关重要的。