我正在使用Linux（3.4.31）嵌入式系统从JFFS2分区启动 . 在删除其他文件时发生断电时，我经常遇到文件损坏问题 . 它发生在平台的升级过程中 . 这些是升级的简化步骤：
-
下载包含（以及其他文件）rootfs.squashfs我正在升级到的文件系统的图像的tar.gz，验证图像的md5校验和 .
-
从一个小型JFFS2分区启动Linux，该分区具有执行升级所需的最少工具集 .
-
挂载必须升级的大分区 .
-
挂载存储在大分区中的rootfs.squashfs .
-
从大分区中删除所有文件，除了一些迁移的数据文件，rootfs.squashfs图像等 .
-
将挂载的rootfs.squashfs中的所有文件复制到大分区
-
从大分区引导
所述功率损耗发生在5.步骤中 . 请注意，rootfs.squashfs以只读方式挂载，在升级期间永远不会更改 . 即使此文件已损坏，并且在设备启动后，您可以看到文件的md5校验和不同，大小保持不变，可以安装映像，但无法从此映像读取某些文件 .
为什么这个文件被破坏了？ JFFS2不应该处理这种情况吗？有没有办法从这种情况中恢复过来？
1 回答
不久之前，我确实看到了打开并被写入的文件的损坏 . 等待超过fs提交时间（默认为5秒）解决了问题 . 这意味着在从tar.gz中提取所有文件后的第1步中，7秒的睡眠将使fs稳定下来并刷新到闪存 . 如果这对你有用，请告诉我们 .
一个足够小的分区，以便gc过于频繁地收集或早期收集可能会过早地擦除以前的日志 . 随后可能导致回滚太浅，因此文件可能最终处于损坏状态 . 这是我对jffs2算法的解读，未经专家或实践验证 .
给定这些视图，在触摸文件（写入，删除）之后，将需要7秒的睡眠 .
也许需要两组相同的文件 . 每个集合将被写入除了前一个集合之外的时间间隔长于提交时间，例如， 7秒上电后，确定哪个集仍然有效并使用有效集 .
关于jffs的信息非常少 . 我的一些看法只是猜测，有些猜测是在有限条件下进行测试的 . 因此，我无法保证观点是正确的 . 当我在jffs区域筛选内核提交时，很明显很难跟踪哪个版本有什么错误，以及何时修复了这些错误 . 也许如果你尝试不同的版本，问题会有所不同 .