3

我们有许多嵌入式系统需要对文件系统进行读/写访问，这些文件系统驻留在具有块设备仿真的闪存存储上。我们最古老的平台在紧凑型闪存上运行，这些系统已经使用了 3 年以上，在启动期间没有运行单个 fsck，到目前为止，我们没有任何故障归因于文件系统或 CF。

在我们最新的平台上，我们使用 USB 闪存进行初始生产，现在正在迁移到 Disk-on-Module 进行读写存储。不久前，我们在 USB 存储上运行的许多设备上的文件系统存在一些问题，因此我启用了 e2fsck 以查看是否有帮助。事实证明，我们收到了一批坏闪存，因此一旦更换了这些闪存，问题就消失了。从那以后我禁用了 e2fsck，因为我们没有迹象表明它使系统更加可靠，而且从历史上看，没有它我们一直很好。

现在我们已经开始放入 Disk-on-Module 单元，我又开始看到文件系统错误。突然系统无法读取/写入某些文件，如果我尝试从紧急控制台访问该文件，我只会收到“输入/输出错误”。我再次启用了 e2fsck 并更正了所有文件。

O'Reilly 的“构建嵌入式 Linux 系统”建议在 ext2 文件系统上运行 e2fsck，但没有提及与 ext3 相关的内容，所以我对是否应该启用它有点困惑。

您对在嵌入式系统上运行 fsck 有何看法？我们正在考虑将二进制文件放在 ar/o 分区上，并且只将必须修改的文件放在同一闪存设备上的 ar/w 分区上，以便 fsck 永远不会意外删除重要的系统二进制文件，有没有人有这种设置的经验（好坏）？

4

2 回答 2

4

我认为您的问题的答案更多地与您的应用程序相对于其数据的一致性要求类型有关。也就是说，如果在没有正式关闭系统的情况下断电，必须保证什么？一般来说，如果没有特定的应用程序关闭/同步文件和刷新磁盘缓存等，在应用程序的关键事务点，没有一个桌面操作系统类型的文件系统可以很好地处理这一切，以确保您需要维护的内容在事实向媒体承诺。

运行 fsck 会修复文件系统，但如果没有上述注意，则无法保证您所做的更改将实际保留。即：由于电源故障，您将失去什么并不是完全确定的。

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

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

于 2009-01-26T14:46:08.147 回答
2

戴夫，

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

原因是，ext3 是日志型的。因此，除非您启用回写（无日志），否则大多数情况下，您的元数据/文件系统表应该与您的数据（文件）同步。

但就像 Jeff 提到的，它不能保证文件系统之上的层。这意味着，您仍然会得到“损坏”的文件，因为某些记录可能没有写入文件系统。

我不确定您在哪个嵌入式设备上运行，但它多久重新启动一次？如果它是受控重启，您可以在重启前执行“同步；同步；同步”。

我自己使用 CF 已经很多年了，而且在极少数情况下我会遇到文件系统错误。fsck 确实对这种情况有所帮助。

关于分离你的分区，我怀疑它的优势。对于文件系统上的每个数据/文件，都有一个与之关联的元数据。大多数情况下，如果您不更改文件，例如。二进制/系统文件，则此元数据不应更改。除非您的硬件有故障，例如串扰读写，否则那些只读文件应该是安全的。

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

希望有帮助。

于 2009-01-30T18:12:03.013 回答