Do we need an opt-in for file systems use of hw atomic writes?

[John Garry]

On 15/07/2025 10:03, Christoph Hellwig wrote:
> On Tue, Jul 15, 2025 at 09:42:33AM +0100, John Garry wrote:
>>> I'm not sure a XFLAG is all that useful.  It's not really a per-file
>>> persistent thing.  It's more of a mount option, or better persistent
>>> mount-option attr like we did for autofsck.
>>
>> For all these options, the admin must know that the atomic behaviour of
>> their disk is as advertised - I am not sure how realistic it is.
> 
> Well, who else would know it, or rather who else can do the risk
> calculation?
> 
> I'm not worried about Oracle cloud running data bases on drives written
> to their purchase spec and validated by them.
> 
> I'm worried about $RANDOMUSER running $APPLICATION here that thing
> atomic write APIs are nice (they finally are) and while that works
> fine with the software implemenetation and even reasonably high end
> consumer devices, they now get the $CHEAPO SSD off Alibab and while
> things work fine their entire browinshistory / ledger / movie data
> base or whatever is toast and the file system gets blamed.
> 
> 
Hi Christoph,

nothing has been happening on this thread for a while. I figure that it 
is because we have no good or obvious options.

I think that it's better deal with the NVMe driver handling of AWUPF 
first, as this applies to block fops as well.

As for the suggestion to have an opt-in to use AWUPF, you wrote above 
that users may not know when to enable this opt-in or not.

It seems to me that we can give the option, but clearly label that it is 
potentially dangerous. Hopefully the $RANDOMUSER with the $CHEAPO SSD 
will be wise and steer clear.

If we always ignore AWUPF, I fear that lots of sound NVMe 
implementations will be excluded from HW atomics.

Thanks,
John