Re: [PATCH v6 11/12] xfs: add xfs_compute_atomic_write_unit_max()

[John Garry]

On 09/04/2025 23:49, Dave Chinner wrote:
> > You did provide a relatively large value in 16MB. When I say relative, I
> > mean relative to what can be achieved with HW offload today.
> >
> > The target user we see for this feature is DBs, and they want to do writes
> > in the 16/32/64KB size range. Indeed, these are the sort of sizes we see
> > supported in terms of disk atomic write support today.
> The target user I see for RWF_ATOMIC write is applications
> overwriting files safely (e.g. config files, documents, etc).
>
> This requires an atomic write operation that is large enough to
> overwrite the file entirely in one go.
>
> i.e. we need to think about how RWF_ATOMIC is applicable to the
> entire userspace ecosystem, not just a narrow database specific
> niche. Databases really want atomic writes to avoid the need for
> WAL, whereas application developers that keep asking us for safe
> file overwrite without fsync() for arbitrary sized files and IO.

If they want to use this API, then arbitrary-sized files will need to be 
power-of-2 sized files (if the user is happy to atomic update all of the 
file).

I would have thought that the work Christoph did with O_ATOMIC a few 
years ago for atomic file updates would be more suited for scenario 
which you mention.

Anyway, back to the main topic..

What is the method you propose that the admin can use to fix this upper 
atomic write limit? Is this an mkfs and/or mount option?

I appreciate that I am asking the same question as Darrick did in his 
follow up mail.

John