On Fri, 2025-08-29 at 13:24 +0200, Ahmad Fatoum wrote: > > 2. Barebox is a much higher quality code base to work in than > > U-Boot. I'm sorry, but it just is. > > > > Barebox would thus take the place occupied by systemd-boot in many > > distro setups. So why not go with systemd-boot? > > Sidenote: Something that been irking me for ages is the over-reliance > on FAT in systemd-boot. Could the FAT on a file system level break > by inopportune power cuts? We go to great lengths with barebox-state > and redundant buckets on raw partitions to avoid this and it leaves > me asking: Was I wrong to mistrust FAT or is a sudden power cut during > file system write operations not as much a concern for their users? > > I hope someone (maybe me instead of talking) should do fault injection > in QEMU or using kernel APIs and see how broken it can get.
For the kernel, there is: https://docs.kernel.org/admin-guide/device-mapper/log-writes.html https://github.com/josefbacik/log-writes Perhaps this could be used via the sandbox build or even QEMU to produce such a log. Then, you could use the userspace tool to reproduce all intermediate states and check that they are consistent. Doing this has been on my wishlist for ages, but I've never gotten around to it. Also in this area, I've wondered for some time if an alternative implementation of FAT would be possible which does a strictly ordered commit of a new meta-data tree on unmount. As there are two copies of the top-level FAT, it might be possible to do that atomically by using a careful ordering of writes. By now, FAT is basically only used as a boot partition, so trading performance for reliability might be a good idea. :) Regards, Jan -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
