EC2:关闭 EBS 卷的 fsck 有多危险?

EC2:关闭 EBS 卷的 fsck 有多危险?

我一直在绞尽脑汁想弄清楚为什么我的 EC2 实例(由我自己的自定义 AMI 制作)需要多次尝试才能正常启动。它们会失败并出现以下错误:

fsck.ext3:尝试打开 /dev/sdf 时没有此文件或目录

对于我在启动期间附加的两个 EBS 卷。

最后,我找到了问题所在。我把这个放在了 /etc/fstab 中:

/dev/sdf /export ext3 defaults 1 2 
/dev/sdi /export2 ext3 defaults 1 2 

2 告诉系统在启动过程中对驱动器进行 fsck。将其更改为

/dev/sdf /export ext3 defaults 1 0 
/dev/sdi /export2 ext3 defaults 1 0 

完全避免了这个问题,但现在卷永远不会被 fsck 了。这有多重要?一旦实例投入生产,它就会几乎全天候运行,所以无论如何也不会发生太多的 fsck,但是……这感觉是个坏主意。

我找不到其他人报告这个问题(有些人有相同的错误消息,但原因不同)。我竟然是唯一犯过这种错误的人,这似乎令人难以置信,但也许我就是这么有天赋。:) 如果有其他解决方案,我很乐意听听;我还没找到。

答案1

每次启动实例时不需要执行 fsck,这是肯定的。

我觉得你可以向 10 位管理员询问何时进行 fsck 的问题并得到 15 个答案。

我的看法是,仅当您在日志中看到文件系统错误或文件系统被严重破坏时才应该这样做。

如果你想做更多研究,我会搜索一般的 fsck 建议。fsck 是针对文件系统本身的。其背后的数据存储应该无关紧要。

相关内容