我正在将产品从 jffs2 文件系统迁移到 ubifs。
以前的 jffs2 设计包含 3 个 mtd 分区（2 个 ro 和 1 个 rw）。
转向 ubifs - 我应该创建：
基本上我在问是否应该在迁移到 ubifs 时将分区替换为卷？ （我的理解是，如果这样做，ubi 层将管理整个闪存）
谢谢， 然
【问题讨论】：
标签： linux-kernel filesystems embedded-linux jffs2 ubifs
选项存在，这里是好处...
一个 mtd 分区和 3 个卷
UBI 层将管理卷。这是一个闪存虚拟化层，它将不可靠的闪存转换为可靠的内存。 UBI 层执行磨损均衡。即使对于只读数据，偶尔重写数据也是有益的。这将为浮动门等充电，以便数据保持更长时间的可读性。对于读写数据，它对长寿非常有益。 UBI 磨损均衡将在所有卷上进行。这大大增加了文件系统可以处理的擦写周期。
3 个 mtd 分区，每个 1 个卷
这通常不太理想，但有好处，并且可能适合某些用户。主要有一个单独的分区增加了安装单个卷的可靠性。如果单个 MTD 分区出现问题，那么您的整个闪存可能会变得无法使用。通过具有单独的 MTD 分区，当读写文件系统失败时，只读 MTD/UBI/UbiFS 系统可能是可用的。
这确实对第三种选择更有利，
具有混合文件系统的多个 MTD。
可以将 CramFS、RomFS 放在某些闪存设备中，其中设备块由制造商保证可靠。这可能是一个引导文件系统，它是系统最低限度运行所需的全部。操作这些分区的工具非常简单（与 UBI/UbiFS 相比）并且可以在最小的代码空间中实现。一些系统具有较大的 DDR 和较小的片上 SRAM。加载程序/闪存可能有有限的代码空间。
也就是说，最近（过去两年）mtd-utils 包含 UBI 解析代码。这可能需要移植到闪存、恢复代码等。恢复代码可能在附加的 initrd 分区中，该分区执行 UBI/UbiFS 分区的挂载/故障安全恢复。
u-boot 包含用于管理和操作 UBI/UbiFS 代码的代码，它在许多平台上使用两阶段启动（从内部 SRAM 运行、配置 DDR 然后迁移）以具有丰富的功能引导加载程序。 u-boot 本身需要在另一台设备上或 在单独的 MTD 中，如上所示。
第二个选项3 个 mtd 分区，每个 1 个卷可能是最不可能/最不希望的。第一个将有利于系统/闪存寿命。最后一个将提供更高可靠性/恢复的简单性。 最佳将取决于分区上的数据以及可用于恢复数据的非 Linux 资源。最好的办法是为 UBI 提供尽可能多的 NAND 闪存空间，并在需要逻辑分区时使用卷。
通常，我会质疑为什么要使用卷并在这种情况下将所有数据放在一起，但这又取决于数据的性质。
【讨论】：