Re: Is rename(2) atomic on FAT?

[Richard Weinberger <richard@nod.at>]

----- Ursprüngliche Mail -----
> Von: "Chris Murphy" <lists@colorremedies.com>
> An: "richard" <richard@nod.at>
> CC: "Chris Murphy" <lists@colorremedies.com>, "Pali Rohár" <pali.rohar@gmail.com>, "linux-fsdevel"
> <linux-fsdevel@vger.kernel.org>
> 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@nod.at> 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