2

In the pre-ubifs days it was common practice in embedded systems to setup several (MTD) partitions in flash for protection. For example, a partition containing a read-only file system could be mounted as /, with a separate writeable partition for configuration data mounted as /home or /data or whatever.

On the other hand, one of the main features of UBI is that it provides logical "UBI volumes" while at the same time doing wear-leveling across the whole flash device. Quoting from the MTD website:

UBI implements wear-leveling across whole flash device (i.e., you may continuously write/erase only one logical eraseblock of an UBI volume, but UBI will spread this to all physical eraseblocks of the flash chip);

My question is: Does it make sense to have separate UBI volumes for, e.g. a read only file system vs configuration data? Or is this pointless due to the fact that the whole flash participates in wear-leveling internally?

Grodriguez
  • 906
  • 2
  • 11
  • 31
  • The read-only system vs. the rest seems to be good idea for several other reasons, e.g. it's easier to reset (simply purge the content of the partitions that aren't read-only) and harder to break. – phk Oct 27 '16 at 21:07
  • Yes, of course, the benefits of a ROFS are clear. The question is whether it makes sense to put it in a separate UBI volume (you can as well mount your filesystem as RO, then a specific dir such as /home or /data as RW using a bind mount. This can all be in the same UBI volume) – Grodriguez Oct 27 '16 at 21:32
  • I am no expert on UBIFS but I have an embedded device here which apparently has multiple UBI volumes (`/dev/mtdblockX` → "UBI device number N"), one where the boot images are which is apparently mounted on boot by the bootloader (if you boot from flash) and then later again by the OS and one for the writable space. The boot images booted represents RO `/`. Now in this case the justification could have been to keep the space with the boot images separate. – phk Oct 27 '16 at 21:48

1 Answers1

2

Yes, it can certainly make sense. Embedded systems will commonly keep two or more separate bootable images on the flash. This way, they can erase and upgrade one, and fall back to the other if the upgrade fails. If you're keeping your root filesystem and your configuration data on the same volume, you're making your upgrade process a lot more complicated, since you have to manage moving the configuration data to the new volume (and track down which data is "correct" in the various failure/fallback cases).

So keeping static program data on a separate volume from mutable configuration data is a good idea in general. Considering UBIFS specifically, there are several options:

  • Keep the rootfs in a squashfs atop a raw UBI volume. You can use the MTD_UBI_BLOCK kernel option to present a UBI volume as a block device, and mount the squashfs from there. In this case you could potentially write a new image directly from U-Boot, since U-Boot can write raw UBI volumes but can only read files on a UBIFS.
  • Keep the rootfs as a separate UBIFS. This takes a lot of extra space, as UBIFS is much less efficient than squashfs at storing filesystem metadata, and if your rootfs is read-only, there's no real benefit.
  • Keep the rootfs as a squashfs file on the UBIFS volume, and loop-mount it. This uses a little extra space (the metadata for the rootfs file itself), but has extra flexibility, since you don't have to worry about how much space to reserve for boot images vs. configuration data. (However, this flexibility could be a bad thing if you accidentally use up all your space on boot images.)
  • Keep the rootfs directly on MTD. This loses the wear-leveling benefits entirely for the rootfs, and decreases wear-leveling effectiveness for the writable volumes, since there are fewer erase blocks available to rotate through.
Jander
  • 16,272
  • 6
  • 50
  • 66