由于关闭不当 (fs ext4) 导致 Linux 文件系统损坏？

Question

我一直在管理许多 Linux 服务器，Linux 服务器比任何其他操作系统都更容易玩。但有时我遇到 Linux 操作系统的一个问题是，文件系统损坏。此问题在 Windows 服务器中不会​​发生。

我在网上详细搜索了解决方案，大部分都是大家给的建议。

1. 保留备份和恢复

我的评论 ==> 100% 同意，但我正在寻找解决方案，我不需要为恢复崩溃的操作系统而苦苦挣扎。

2. 运行 fsck

我的评论 ==> 根据我的经验，有时会引入其他问题。

3. 进行适当的关机/重启。

我的评论 ==> 每个人都想正确关机/重启。我说的是一种罕见的情况，即服务器没有响应或我无法正确关闭或重新启动

4. Btrfs ==>

我的评论 ==> 对于生产来说不够稳定

5. 升级到 Ext4

我的评论 ==> 已经在使用 ext4

6. 升级你的硬盘 My Comments ==> 我们遇到的问题不是因为磁盘故障，主要是因为关机不当。

我的 fsck 问题：

1. 当我们使用 -y 选项运行时，fsck 有时会损坏文件系统

2. fsck 大约需要 1 到 2 天的时间来修复系统，这对我在生产环境中是不合适的

我的问题是，在 btrfs 变得稳定之前，有没有办法解决这个问题？

比如，在几分钟内“同步”一次文件系统。或编写一些脚本以在重新启动之前同步所有文件系统更改

我正在寻找解决此问题的方法而不是建议。

Answer 1

ext4 应该具有弹性，甚至可以拉动插头。然而，为了做到这一点，它要求存储子系统不丢失已提交的写入。

首先，确认您没有安装barrier=0/ nobarrier。这通常会提高性能，但代价是如果未执行适当的关闭，则会导致损坏。还要检查您的内核日志以确保 ext4 没有禁用屏障，因为堆栈中的某些内容不支持它们。

接下来要尝试的事情，至少在磁性（非 SSD）磁盘上是禁用磁盘写入缓存。有时，磁盘会在实际将数据写入盘片时撒谎——它可以提高性能（只要不断电）。通常，您可以使用hdparm -W0（对于 IDE/SATA）或sdparm --clear=WCE（对于 SCSI/SAS）来执行此操作。这些可能需要添加到您的引导脚本中，特别是对于 SATA，它可能会通过电源循环重置为默认值。

有一个（相当旧的）脚本来确认写缓存不会丢失数据；有关脚本及其使用方法，请参阅Brad Fitzpatrick 的 diskchecker.pl 博客文章。

如果您使用的是 SSD 并且发现了问题，不幸的是，您可能只需要找到不同的磁盘。