ubifs 卷与 mtd 分区

Posted 2023-02-16

【中文标题】ubifs 卷与 mtd 分区

【英文标题】：ubifs volumes vs. mtd partitions

【发布时间】：2016-10-10 14:41:06

【问题描述】：

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

以前的 jffs2 设计包含 3 个 mtd 分区（2 个 ro 和 1 个 rw）。

转向 ubifs - 我应该创建：

一个 mtd 分区和 3 个卷 3 个 mtd 分区，每个 1 个卷

基本上我在问是否应该在迁移到 ubifs 时将分区替换为卷？ （我的理解是，如果这样做，ubi 层将管理整个闪存）

谢谢， 然

【参考方案1】：

选项存在，这里是好处...

一个 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 闪存空间，并在需要逻辑分区时使用卷。

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

【讨论】：

感谢您的详细解答。我选择了基于体积的设计。

如果您对 UBI/UbiFS 堆栈有信心，通常卷设计会更好。某些可靠性取决于 MTD 驱动程序。如果这个 fs 堆栈没有失败（即使有奇怪的电源循环），那么体积设计总是更好。只有具有容错要求的电池供电设计可能需要分区。分区是开发 MTD 驱动程序时要走的路。