----- Ursprüngliche Mail ----- > Von: "Chris Murphy" <lists@xxxxxxxxxxxxxxxxx> > An: "richard" <richard@xxxxxx> > CC: "Chris Murphy" <lists@xxxxxxxxxxxxxxxxx>, "Pali Rohár" <pali.rohar@xxxxxxxxx>, "linux-fsdevel" > <linux-fsdevel@xxxxxxxxxxxxxxx> > Gesendet: Freitag, 25. Oktober 2019 11:22:17 > Betreff: Re: Is rename(2) atomic on FAT? > On Fri, Oct 25, 2019 at 12:33 AM Richard Weinberger <richard@xxxxxx> wrote: >> >> ----- Ursprüngliche Mail ----- >> >> U-boot, for example. Of course it does not so for any filesystem, but whe= >> > re >> >> it is needed and makes sense. >> > >> > Really? uboot does journal replay on ext3/4? I think at this point the >> > most common file system on Linux distros is unquestionably ext4, and >> > the most common bootloader is GRUB and for sure GRUB is no doing >> > journal replay on anything, including ext4. >> >> For ext4 it does a replay when you start to write to it. > > That strikes me as weird. The bootloader will read from the file > system before it writes, and possibly get the wrong view of the file > system's true state because journal replay wasn't done. This can't happen. U-boot is strictly single threaded, no interrupts, no nothing. For the ext4 case in U-boot, it does a replay not to have clean file system upon read but to not corrupt it upon write. For UBIFS, for example, U-boot does a replay also before reading. But it replays into memory. The journal size is fixed and known, so no big deal. >> > Yeah that's got its own difficulties, including the way distro build >> > systems work. I'm not opposed to it, but it's a practical barrier to >> > adoption. I'd almost say it's easier to make Btrfs $BOOT compulsory, >> > make static ESP compulsory, and voila! >> >> I really don't get your point. I thought you are designing a "sane" >> system which can tolerate powercuts down an update. >> Why care about distros? >> The approach with Linux being a "bootloader" is common for embedded/secure >> systems. > > I want something as generic as possible, so as many use cases have > reliable kernel/bootloader updates as possible, so that fewer users > experience systems face planting following such updates. Any system > can experience an unscheduled, unclean shutdown. Exceptions to the > generic case should be rare and pretty much be about handling hardware > edge cases. Don't forget UEFI updates. ;-) Really, you can't have it all on a x86 system in such a generic way. Thanks, //richard
