[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b270bb66-721e-4433-adaf-fe5ae100ca6e@oracle.com>
Date: Thu, 17 Jul 2025 15:06:01 +0100
From: John Garry <john.g.garry@...cle.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
Cc: Zorro Lang <zlang@...hat.com>, fstests@...r.kernel.org,
Ritesh Harjani <ritesh.list@...il.com>, djwong@...nel.org,
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 17/07/2025 14:52, Ojaswin Mujoo wrote:
> On Thu, Jul 17, 2025 at 02:00:18PM +0100, John Garry wrote:
>> On 12/07/2025 15:12, Ojaswin Mujoo wrote:
>>> From: "Ritesh Harjani (IBM)" <ritesh.list@...il.com>
>>>
>>> This adds atomic write test using fio based on it's crc check verifier.
>>> fio adds a crc for each data block. If the underlying device supports atomic
>>> write then it is guaranteed that we will never have a mix data from two
>>> threads writing on the same physical block.
>>
>> I think that you should mention that 2-phase approach.
>
> Sure I can add a comment and update the commit message with this.
>
>>
>> Is there something which ensures that we have fio which supports RWF_ATOMIC?
>> fio for some time supported the "atomic" cmdline param, but did not do
>> anything until recently
>
> We do have _require_fio which ensures the options passed are supported
> by the current fio. If you are saying some versions of fio have --atomic
> valid but dont do an RWF_ATOMIC then I'm not really sure if that can be
> caught though.
Can you check the fio version?
>
>>
>>>
>>> Co-developed-by: Ritesh Harjani (IBM) <ritesh.list@...il.com>
>>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@...il.com>
>>> Signed-off-by: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
>>> ---
>>> tests/generic/1226 | 101 +++++++++++++++++++++++++++++++++++++++++
>>> tests/generic/1226.out | 2 +
>>
>> Was this tested with xfs?
>
> Yes, I've tested with XFS with software fallback as well. Also, tested
> xfs while keeping io size as 16kb so we stress the hw paths too.
so is that requirement implemented with the
_require_scratch_write_atomic check?
> Both
> seem to be passing as expected.
>>
Powered by blists - more mailing lists