JFFS2中的文件在删除其他文件时停电后损坏的原因

Question

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

1. 下载tar.gz，包含(以及其他文件)我正在升级的文件系统的rootfs.squashfs映像，验证图像的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中，7秒的睡眠将允许fs稳定下来并被刷新到闪存。如果这对你有用，请告诉我们。

一个分区足够小，以至于gc收集得太频繁或太早，可能会过早地删除以前的日志。这可能会导致回滚太浅，因此文件最终可能处于损坏状态。这是我对jffs2算法的解读，还没有得到专家的验证，也没有在实践中得到验证。

考虑到这些视图，在触摸文件(写、删除)之后，将需要7秒的睡眠。

可能需要两组相同的文件。每个集合将以比提交时间更长的时间间隔(例如，7秒)写入到与前一组不同的集合中。打开电源后，确定哪些设置仍然有效，并使用有效集。

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