在 ubifs 出现之前，嵌入式系统中的常见做法是在闪存中设置多个 (MTD) 分区以进行保护。例如，包含只读文件系统的分区可以安装为 /，而用于配置数据的单独可写分区则安装为 /home 或 /data 等。
另一方面，UBI 的主要特点之一是它提供逻辑“UBI 卷”，同时在整个闪存设备上进行磨损均衡。引用自MTD网站：
UBI在整个闪存设备上实现磨损均衡（即，您只能连续写入/擦除UBI卷的一个逻辑擦除块，但UBI会将其扩展到闪存芯片的所有物理擦除块）；
我的问题是：为只读文件系统与配置数据等设置单独的 UBI 卷是否有意义？还是因为整个闪存都在内部参与磨损均衡，所以这毫无意义？
答案1
是的，这当然有道理。嵌入式系统通常会在闪存上保存两个或多个单独的可启动映像。这样，他们就可以擦除并升级一个，如果升级失败，则可以回退到另一个。如果您将根文件系统和配置数据保留在同一卷上，那么您的升级过程就会变得更加复杂，因为您必须管理将配置数据移动到新卷（并追踪哪些数据是“在各种失败/后备情况下正确”）。
因此，将静态程序数据与可变配置数据保存在单独的卷上通常是一个好主意。具体考虑 UBIFS，有以下几种选择：
- 将 rootfs 保存在原始 UBI 卷顶部的 squashfs 中。您可以使用 MTD_UBI_BLOCK 内核选项将 UBI 卷呈现为块设备，并从那里挂载 squashfs。在这种情况下，您可能会直接从 U-Boot 写入新映像，因为 U-Boot 可以写入原始 UBI 卷，但只能读取 UBIFS 上的文件。
- 将 rootfs 保留为单独的 UBIFS。这需要大量的额外空间，因为 UBIFS 在存储文件系统元数据方面比 squashfs 效率低得多，并且如果您的 rootfs 是只读的，则没有真正的好处。
- 将 rootfs 作为 squashfs 文件保留在 UBIFS 卷上，并循环挂载它。这会使用一点额外的空间（rootfs 文件本身的元数据），但具有额外的灵活性，因为您不必担心为启动映像和配置数据保留多少空间。 （但是，如果您不小心用完了启动映像上的所有空间，这种灵活性可能是一件坏事。）
- 将 rootfs 直接保留在 MTD 上。这完全失去了 rootfs 的磨损均衡优势，并降低了可写卷的磨损均衡有效性，因为可循环使用的擦除块较少。