代码之家 › 专栏 › 技术社区 › David Holm

我应该在嵌入式系统上fsck ext3吗?

ext3 filesystems embedded linux

David Holm · 技术社区 · 17 年前

我们有许多嵌入式系统需要通过块设备仿真对驻留在闪存上的文件系统进行远程访问。我们最古老的平台运行在紧凑型闪存上,这些系统已经使用了3年多,在启动过程中没有运行任何fsck,到目前为止,我们还没有发现文件系统或CF导致的故障。

在我们最新的平台上,我们最初使用USB闪存进行生产,现在正在迁移到模块上的磁盘进行r/w存储。不久前,我们在USB存储上运行的许多设备上的文件系统都出现了一些问题,所以我启用了e2fsck,看看这是否有帮助。事实证明,我们收到了一批坏闪存,所以一旦更换了,问题就消失了。自那以后,我禁用了e2fsck,因为我们没有迹象表明它使系统变得更加可靠,而且从历史上看,没有它我们也很好。

现在我们已经开始在模块单元上安装磁盘,我又开始看到文件系统错误。突然间,系统无法读取/写入某些文件,如果我尝试从紧急控制台访问该文件,我只会得到“ 输入/输出错误 “。我再次启用了e2fsck,所有文件都已更正。

奥” 构建嵌入式Linux系统 “建议在ext2文件系统上运行e2fsck,但没有提到它与ext3的关系,所以我有点困惑是否应该启用它。

您对在嵌入式系统上运行fsck有什么看法?我们正在考虑将二进制文件放在r/o分区上,只放在同一闪存设备上的r/w分区上必须修改的文件,这样fsck就不会意外删除重要的系统二进制文件,有人有这种设置的经验吗(好/坏)?

2 回复 | 直到 17 年前

Tall Jeff 17 年前

我认为你的问题的答案更多地与你的应用程序对其数据有什么类型的一致性要求有关。也就是说,如果在没有正式关闭系统的情况下断电,必须保证什么?一般来说,如果不在应用程序的关键事务点关闭/同步文件和刷新磁盘缓存等特定应用程序,以确保您需要维护的内容实际上已提交给媒体,那么桌面操作系统类型的文件系统都无法很好地处理这些问题。

运行fsck可以修复文件系统,但如果没有上述注意事项,就无法保证您所做的更改会被实际保留。ie:停电后你会失去什么,这并不是完全确定的。

我同意将二进制文件或其他重要的只读数据放在单独的只读分区上确实有助于确保它们不会因文件系统结构的fsck更正而被错误地丢弃。至少,将它们放在根目录之外与R/W数据保存位置不同的子目录中会有所帮助。但在这两种情况下,如果你支持软件更新,你仍然需要有一个方案来处理写入“只读”区域的问题。

在我们的应用程序中,我们实际上为二进制文件等内容维护了一对目录,系统设置为从这两个区域中的任何一个启动。在软件更新期间,我们更新第一个目录,将所有内容同步到媒体,并在进入第二个副本的更新之前验证磁盘上的MD5校验和。在启动过程中,它们仅在MD5校验和良好时使用。这可确保您始终启动连贯的映像。

KOkon 17 年前

戴夫,

我总是建议在多次重新启动后运行fsck,但不是每次。

原因是ext3是日志式的。因此,除非您启用回写(无日志),否则大多数时候,您的元数据/文件系统表应该与您的数据(文件)同步。

但正如Jeff提到的,它并不能保证文件系统之上的层。这意味着,你仍然会得到“损坏”的文件,因为一些记录可能没有写入文件系统。

我不确定你运行的是什么嵌入式设备,但它多久重启一次? 如果是受控重启,您始终可以在重启前执行“sync;sync;sync”。

我自己使用CF已经很多年了,很少出现文件系统错误。 fsck确实在这个案子上提供了帮助。

关于分隔分区,我怀疑它的优势。对于文件系统上的每个数据/文件,都有一个与之相关的元数据。大多数时候,如果你不更改文件,例如二进制/系统文件,那么这个元数据就不应该更改。除非你的硬件有故障,比如串扰写入和输出;读,那些只读文件应该是安全的。

当你有可写的东西时,大多数问题都会出现,无论你把它放在哪里,如果应用程序不能很好地处理它,都会导致问题。

希望这能有所帮助。