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: <22ccfefc-1be8-4942-ac27-c01706ef843e@oracle.com>
Date: Thu, 31 Jul 2025 08:58:59 +0100
From: John Garry <john.g.garry@...cle.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>,
        "Darrick J. Wong"
 <djwong@...nel.org>
Cc: 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 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.

> 
> 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.

Thanks,
John


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ