[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <66470caf-ec35-4f7d-adac-4a1c22a40a3e@oracle.com>
Date: Mon, 20 Oct 2025 11:33:40 +0100
From: John Garry <john.g.garry@...cle.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>, Zorro Lang <zlang@...hat.com>
Cc: 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 v7 04/12] ltp/fsx.c: Add atomic writes support to fsx
On 06/10/2025 14:20, Ojaswin Mujoo wrote:
> Hi Zorro, thanks for checking this. So correct me if im wrong but I
> understand that you have run this test on an atomic writes enabled
> kernel where the stack also supports atomic writes.
>
> Looking at the bad data log:
>
> +READ BAD DATA: offset = 0x1c000, size = 0x1803, fname = /mnt/xfstests/test/junk
> +OFFSET GOOD BAD RANGE
> +0x1c000 0x0000 0xcdcd 0x0
> +operation# (mod 256) for the bad data may be 205
>
> We see that 0x0000 was expected but we got 0xcdcd. Now the operation
> that caused this is indicated to be 205, but looking at that operation:
>
> +205(205 mod 256): ZERO 0x6dbe6 thru 0x6e6aa (0xac5 bytes)
>
> This doesn't even overlap the range that is bad. (0x1c000 to 0x1c00f).
> Infact, it does seem like an unlikely coincidence that the actual data
> in the bad range is 0xcdcd which is something xfs_io -c "pwrite" writes
> to default (fsx writes random data in even offsets and operation num in
> odd).
>
> I am able to replicate this but only on XFS but not on ext4 (atleast not
> in 20 runs). I'm trying to better understand if this is a test issue or
> not. Will keep you update.
Hi Ojaswin,
Sorry for the very slow response.
Are you still checking this issue?
To replicate, should I just take latest xfs kernel and run this series
on top of latest xfstests? Is it 100% reproducible?
Thanks,
John
Powered by blists - more mailing lists