linux内核mtd分区,linux-kernel – ubifs卷与mtd分区

我正在将产品从jffs2文件系统迁移到ubifs.

以前的jffs2设计包含3个mtd分区(2 ro和1 rw).

转向ubifs – 我应该创建：

>一个mtd分区和3个卷

> 3 mtd分区,每个1卷

基本上我问我是否应该在转移到ubifs时用卷替换分区？

(我的理解是,如果这样做,ubi层将管理整个闪存)

谢谢,

然

最佳答案 选项存在,这里有好处……One mtd partition and 3 volumes

UBI层将管理卷.这是一个闪存虚拟化层,可将不可靠的闪存转换为可靠的内存. UBI层确实磨损均衡.即使对于只读数据,偶尔重写数据也是有益的.这将为浮动门等充电,以便数据保持更长时间的可读性.对于读写数据,它对于寿命非常有益. UBI磨损均衡将在所有卷上进行.这极大地增加了文件系统可以处理的擦除 – 写入周期.3 mtd partitions, 1 volume each

这通常不太理想,但有一些好处,它可能适合某些用户.主要具有单独的分区增加了安装单个体积的可靠性.如果单个MTD分区出现问题,则整个闪存可能无法使用.通过具有单独的MTD分区,当读写文件系统失败时,可以使用只读MTD / UBI / UbiFS系统.

这对第三种选择更有利,multiple MTD with mixed file systems.

可以将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闪存空间,并在您需要逻辑分区时使用卷.

通常,我会质疑为什么要使用卷,只是在这种情况下将所有数据放在一起,但这又取决于数据的性质.