linux-ext4 - Re: [RFC PATCH 0/8] xfs: single block atomic writes for buffered IO

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87frai8p46.ritesh.list@gmail.com>
Date: Thu, 13 Nov 2025 11:12:49 +0530
From: Ritesh Harjani (IBM) <ritesh.list@...il.com>
To: Christoph Hellwig <hch@....de>, Dave Chinner <david@...morbit.com>
Cc: Ojaswin Mujoo <ojaswin@...ux.ibm.com>, Christian Brauner <brauner@...nel.org>, djwong@...nel.org, john.g.garry@...cle.com, tytso@....edu, willy@...radead.org, dchinner@...hat.com, hch@....de, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, jack@...e.cz, nilay@...ux.ibm.com, martin.petersen@...cle.com, rostedt@...dmis.org, axboe@...nel.dk, linux-block@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/8] xfs: single block atomic writes for buffered IO

Christoph Hellwig <hch@....de> writes:

> On Thu, Nov 13, 2025 at 08:56:56AM +1100, Dave Chinner wrote:
>> On Wed, Nov 12, 2025 at 04:36:03PM +0530, Ojaswin Mujoo wrote:
>> > This patch adds support to perform single block RWF_ATOMIC writes for
>> > iomap xfs buffered IO. This builds upon the inital RFC shared by John
>> > Garry last year [1]. Most of the details are present in the respective 
>> > commit messages but I'd mention some of the design points below:
>> 
>> What is the use case for this functionality? i.e. what is the
>> reason for adding all this complexity?
>
> Seconded.  The atomic code has a lot of complexity, and further mixing
> it with buffered I/O makes this even worse.  We'd need a really important
> use case to even consider it.

I agree this should have been in the cover letter itself. 

I believe the reason for adding this functionality was also discussed at
LSFMM too...  

For e.g. https://lwn.net/Articles/974578/ goes in depth and talks about
Postgres folks looking for this, since PostgreSQL databases uses
buffered I/O for their database writes.

-ritesh