2

我正在使用从 JFFS2 分区引导的 Linux (3.4.31+) 嵌入式系统。在删除其他文件时发生断电时，我经常遇到文件损坏的问题。它发生在平台的升级过程中。这些是升级的简化步骤：

  1. 下载包含（以及其他文件）我要升级到的文件系统的 rootfs.squashfs 映像的 tar.gz，验证映像的 md5 校验和。
  2. 从一个小型 JFFS2 分区引导 linux，该分区具有执行升级所需的最少工具集。
  3. 挂载必须升级的大分区。
  4. 挂载存储在大分区中的 rootfs.squashfs。
  5. 从大分区中删除所有文件，除了一些迁移的数据文件、rootfs.squashfs 映像等。
  6. 将挂载的 rootfs.squashfs 中的所有文件复制到大分区
  7. 从大分区启动

提到的功率损失发生在 5. 步骤中。请注意，rootfs.squashfs 以只读方式安装，并且在升级期间永远不会更改。即使这个文件被损坏并且在设备开机后你可以看到文件的 md5 校验和不同，大小保持不变，图像可以挂载但无法从这个图像中读取一些文件。

为什么这个文件被破坏了？JFFS2 不应该处理这种情况吗？有没有办法从这种情况中恢复过来？

4

1 回答 1

1

不久前，我确实看到打开并写入的文件损坏了。等待超过 fs 提交时间（默认为 5 秒）解决了这个问题。这意味着在从 tar.gz 提取所有文件后的第 1 步中，睡眠 7 秒将使 fs 稳定下来并刷新到闪存中。如果这对您有用，请告诉我们。

分区足够小，以至于 gc 过于频繁或过早地收集可能会过早地删除以前的日志。这随后可能导致回滚太浅，因此文件可能最终处于损坏状态。这是我对 jffs2 算法的阅读，尚未经过专家或实践验证。

鉴于这些视图，在触摸文件（写入、删除）之后，需要 7 秒的睡眠时间。

也许需要两组相同的文件。每个集合将与前一个集合分开一个比提交时间更长的时间间隔，例如 7 秒。上电后，判断哪一组仍然有效，使用有效组。

关于 jffs 的信息很少。我的一些观点只是猜测，一些猜测是在有限的条件下测试得到支持的。因此，我不能保证观点是正确的。当我在 jffs 区域中筛选内核提交时，很明显很难跟踪哪个版本有哪些错误，以及这些错误何时被修复。也许如果您尝试不同的版本，问题会有所不同。

于 2016-01-08T08:16:42.963 回答