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

Question

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

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

上述功率损耗发生在5.步骤中。请注意，rootfs.squashfs以只读方式挂载，在升级期间永远不会更改。即使此文件已损坏，并且设备启动后您可以看到文件的md5校验和不同，大小保持不变，图像可以挂载，但无法从此图像中读取某些文件。 / p>

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

Answer 1

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

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

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

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

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