我们有许多嵌入式系统需要对文件系统进行r / w访问，该文件系统驻留在具有块设备仿真的闪存存储器上。我们最古老的平台运行在紧凑型闪存上，这些系统已经使用了3年多，而且在启动过程中没有运行单个fsck，到目前为止我们没有归因于文件系统或CF的故障。
在我们最新的平台上，我们使用USB闪存进行初始生产，现在正在迁移到磁盘模块以进行硬件存储。前段时间我们在USB存储器上运行的很多设备上遇到了一些文件系统问题，所以我启用了e2fsck以查看是否有帮助。事实证明，我们收到了一批不良闪存，因此一旦被更换，问题就会消失。我已经禁用了e2fsck，因为我们没有任何迹象表明它使系统更加可靠，而且从历史上来说，如果没有它，我们一直很好。
现在我们已经开始使用Disk-on-Module单元，我已经开始再次看到文件系统错误。突然，系统无法读取/写入某些文件，如果我尝试从紧急控制台访问该文件，我只会收到“输入/输出错误”。我再次启用了e2fsck并且所有文件都已更正。
O'Reilly的“构建嵌入式Linux系统”建议在ext2文件系统上运行e2fsck，但是没有提到它与ext3有关，所以我对是否应该启用它有点困惑。在嵌入式系统上运行fsck有什么需要？我们正在考虑将二进制文件放在ar / o分区上，只考虑在同一个闪存设备上的ar / w分区上必须修改的文件，以便fsck永远不会意外删除重要的系统二进制文件，是否有人对这种设置有任何经验（好/坏）？
答案 0 :(得分：4)
我认为您的问题的答案更多地涉及您应用程序相对于其数据的一致性要求类型。也就是说，如果在没有正式关闭系统的情况下断电，必须保证什么？通常，如果没有特定的应用程序关闭/同步文件以及在应用程序中的关键事务点刷新磁盘缓存等，桌面操作系统类型文件系统都不能很好地处理这一点，以确保您需要维护的是事实致力于媒体。
运行fsck会修复文件系统，但如果没有上述保护，则无法保证实际保留的更改。即：由于电力故障，你输掉的东西并不完全确定。
我同意将二进制文件或其他重要的只读数据放在一个单独的只读分区上，这有助于确保它们不会因文件系统结构的fsck更正而错误地被抛出。至少，将它们放在根目录下不同于R / W数据所在的子目录中会有所帮助。但在这两种情况下，如果你支持软件更新，你仍然需要有计划来处理写“只读”区域。
在我们的应用程序中，我们实际上为二进制文件维护了一对目录，系统设置为从两个区域中的任何一个启动。在软件更新期间，我们更新第一个目录，将所有内容同步到介质并验证磁盘上的MD5校验和，然后再转到第二个副本的更新。在引导期间，仅在MD5校验和良好时才使用它们。这可确保您始终启动连贯的图像。
答案 1 :(得分：2)
戴夫，
我总是建议在多次重启后运行fsck，但不是每次都运行。
原因是，ext3是期刊。因此，除非您启用回写（无日志），否则大多数情况下，您的元数据/文件系统表应与您的数据（文件）保持同步。
但是像杰夫提到的那样，它并不保证文件系统上方的层。这意味着，您仍然会收到“损坏”的文件，因为某些记录可能无法写入文件系统。
我不确定您运行的是什么嵌入式设备，但是它多久重启一次？ 如果它是受控重启，您可以在重启之前始终进行“同步;同步;同步”。
我自己多年来一直在使用CF，而且我很少遇到文件系统错误。 fsck对这种情况有帮助。
关于分离您的分区，我怀疑它的优势。对于文件系统上的每个数据/文件，都有与之关联的元数据。大多数情况下，如果您不更改文件，例如。二进制/系统文件，那么这个元数据不应该改变。除非你有一个有缺陷的硬件，比如串扰写和＆amp;读，这些只读文件应该是安全的。
当你有可写的内容时，大多数问题都会出现，无论你把它放在哪里，如果应用程序处理得不好，它都会引起问题。
希望有所帮助。