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