linux-ext4 - Re: [PATCH v3 05/13] generic/1226: Add atomic write test using fio crc check verifier

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: <aIxhsV8heTrSH537@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Fri, 1 Aug 2025 12:11:53 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: John Garry <john.g.garry@...cle.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, Zorro Lang <zlang@...hat.com>,
        fstests@...r.kernel.org, Ritesh Harjani <ritesh.list@...il.com>,
        tytso@....edu, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH v3 05/13] generic/1226: Add atomic write test using fio
 crc check verifier

On Thu, Jul 31, 2025 at 08:58:59AM +0100, John Garry wrote:
> On 31/07/2025 05:18, Ojaswin Mujoo wrote:
> > > Heh, here comes that feature naming confusing again.  This is my
> > > definition:
> > > 
> > > RWF_ATOMIC means the system won't introduce new tearing when persisting
> > > file writes.  The application is allowed to introduce tearing by writing
> > > to overlapping ranges at the same time.  The system does not isolate
> > > overlapping reads from writes.
> > > 
> > > --D
> > Hey Darrick, John,
> > 
> > So seems like my expectations of RWF_ATOMIC were a bit misplaced. I
> > understand now that we don't really guarantee much when there are
> > overlapping parallel writes going on. Even 2 overlapping RWF_ATOMIC
> > writes can get torn. Seems like there are some edge cases where this
> > might happen with hardware atomic writes as well.
> > 
> > In that sense, if this fio test is doing overlapped atomic io and
> > expecting them to be untorn, I don't think that's the correct way to
> > test it since that is beyond what RWF_ATOMIC guarantees.
> 
> I think that this test has value, but can only be used for ext4 or any FS
> which only relies on HW atomics only.
> 
> The value is that we prove that we don't get any bios being split in the
> storage stack, which is essential for HW atomics support.
> 
> Both NVMe and SCSI guarantee serialization of atomic writes.

Hi John,

Got it, I think I can make this test work for ext4 only but then it might 
be more appropriate to run the fio tests directly on atomic blkdev and
skip the FS, since we anyways want to focus on the storage stack.

> 
> > 
> > I'll try to check if we can modify the tests to write on non-overlapping
> > ranges in a file.
> 
> JFYI, for testing SW-based atomic writes on XFS, I do something like this. I
> have multiple threads each writing to separate regions of a file or writing
> to separate files. I use this for power-fail testing with my RPI. Indeed, I
> have also being using this sort of test in qemu for shutting down the VM
> when fio is running - I would like to automate this, but I am not sure how
> yet.
> 
> Please let me know if you want further info on the fio script.

Got it, thanks for the insights. I was thinking of something similar now
where I can modify the fio files of this test to write on non
overlapping ranges in the same file. The only doubt i have right now is
that when I have eg, numjobs=10 filesize=1G, how do i ensure each job
writes to its own separate range and not overlap with each other.

I saw the offset_increment= fio options which might help, yet to try it
out though. If you know any better way please do share.

Thanks,
Ojaswin
> 
> Thanks,
> John
>