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
