Re: [RFC PATCH] fat: add noflush mount option

[David Timber]

On 8/25/26 14:51, Christoph Hellwig wrote:
> On Sun, Aug 23, 2026 at 02:37:32AM +0900, David Timber wrote:
>> On most distros, udisks manages users' removable volume mount requests.
>> Udisks is configured to always mount FAT volumes with the 'flush' mount
>> option. This is largely okay for populating directory in small sizes,
> No, it's not.  It is an amaingly stupid idea that leads to horrible
> performance and flash wearout.  I'm not objecting to your patch, but
It probably had something to do with DOS and/or Windows implementation,
maybe a "monkey see, monkey do" situation. I think this is why FAT on
Windows is quite slow to this day(again, I might be wrong so don't quote
me on this).

Whoever first came up with the idea was probably worried too much about
users(who are not familiar with UNIX systems) unplugging removable
devices without giving the OS an opportunity to sync. I have to say
that, compared to Windows' default behaviour, the default 5 seconds of
vm.dirty_writeback is quite aggressive and that's why we have the flush
option in the first place...

But I still think being able to flip the option on the fly should come
in really handy in embedded systems that just can't afford to do
explicit sync. I think this is the main use case of the flush mount
option. For storing small metadata, it's really not that bad of an idea,
even in terms of hardware degradation.

> if you care about the usability of FAT volumes in this scenario, the
> more important thing is to fix this default.
I'll go to udisks devs to ask why they did this.

Davo