linux - 为什么 JFFS2 中的文件在删除其他文件时断电后会损坏

Question

我正在使用从 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 不应该处理这种情况吗？有什么办法可以从这种情况中恢复过来吗？

Answer 1

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

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

鉴于这些 View ，在触摸文件(写入、删除)后，需要 7 秒的休眠。

可能需要两组相同的文件。每个集合将被写入与前一个集合分开的时间间隔长于提交时间，例如7 秒。上电后，确定哪个组仍然有效并使用有效组。

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