Hi Richard,
Just looked through the slides of your ELCE talk "Current challenges in UBIFS". I would like to elaborate the issues wrt moster boot. I did not attend the talk (sorry) and also was not able to find a video of it so far, hence I don't know what has been said at the talk... So, the last slide says:
* Don’t boot from UBIFS * Your boot loader does not have to know UBIFS nor have full UBI support * Use static volumes, you can read out a static UBI volume with 100 LoC * Thomas Gleixner sent patches for u-boot
Can you elaborate why you disadvise booting from UBIFS?
Here is my analysis on that:
We switched to "monster boot" approach about one year ago. On the plus side, U-Boot had already UBIFS read support and it works. Beside that, it is basically the standard boot mode for distros on PC-like systems (GRUB is able to read the kernel from a ext2/ext3 formatted /boot partition, UEFI reads EFI boot loaders or the kernel with the EFI stub from FAT partitions directly).
I see the obvious pain point: It makes the boot loader much more complex... After all, we had some issues lately, especially with Fastmap (e.g. PEB leaks). However, one thing was related to a driver issue, and after backporting some Fastmap patches from Linux, Fastmap in U-Boot seems to be stable now. Anyway, since these issues were within the U-Boot UBI stack (and below), we would probably would have run into them even when using static volumes (assuming using the full UBI stack of U-Boot). But likely not if we would have used the minimal static volume approach of Thomas Gleixner.... On the other hand, we did not had any problems with the UBIFS part so far... A fallback boot scheme is possible with UBIFS (just have a spare kernel ready) but it suffer from the huge stack...
Another disadvantage with monster boot is that we can't replace the kernel from U-Boot currently since there is no UBIFS write support, however that is not really a problem.
On the advantage side, we do not loose any space (we would likely have to create a larger than necessary Kernel volume to reserve some space in case customers want to load a bigger kernel). And we can use one UBIFS image for multiple modules (multiple device tree in /boot).
I also did some rough performance measurements, and it seems that the overhead of mounting the UBIFS is not all that huge: UBI Attach (without Fastmap): 1.57s UBI Attach (with Fastmap): 0.25s UBIFS Mount: 0.06s Load kernel from FS: 380ms Load DT from FS: 9ms
However, it seems that reading from UBIFS is somewhat slower compared to reading from static volumes: Load kernel from UBI 4.5MB: 316ms Load kernel from UBI 24kB: 6ms
I used the size argument of the ubi read command to avoid reading the whole static volume. This is somewhat ugly to handle since the size need to be stored in environment variables... I am consider implementing a bootubi command which would read only the effective size for a kernel, device tree or initramfs by making use of the individual file headers.
I would be glad if you could comment whether I miss anything...
-- Stefan