linux-kernel - Re: [PATCH v6 11/12] xfs: add xfs_compute_atomic_write_unit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6793c64b-ba1b-4633-9161-6fe4662c4947@oracle.com>
Date: Thu, 10 Apr 2025 09:58:54 +0100
From: John Garry <john.g.garry@...cle.com>
To: Dave Chinner <david@...morbit.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, brauner@...nel.org, hch@....de,
        viro@...iv.linux.org.uk, jack@...e.cz, cem@...nel.org,
        linux-fsdevel@...r.kernel.org, dchinner@...hat.com,
        linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        ojaswin@...ux.ibm.com, ritesh.list@...il.com,
        martin.petersen@...cle.com, linux-ext4@...r.kernel.org,
        linux-block@...r.kernel.org, catherine.hoang@...cle.com
Subject: Re: [PATCH v6 11/12] xfs: add xfs_compute_atomic_write_unit_max()

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