Re: [PATCH v2 09/13] generic/1230: Add sudden shutdown tests for multi block atomic writes

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Fri, Jun 27, 2025 at 05:11:12PM +0100, John Garry wrote:
> On 26/06/2025 12:59, Ojaswin Mujoo wrote:
> > This test is intended to ensure that multi blocks atomic writes
> > maintain atomic guarantees across sudden FS shutdowns.
> > 
> > The way we work is that we lay out a file with random mix of written,
> > unwritten and hole extents. Then we start performing atomic writes
> > sequentially on the file while we parallely shutdown the FS. Then we
> > note the last offset where the atomic write happened just before shut
> > down and then make sure blocks around it either have completely old
> > data or completely new data, ie the write was not torn during shutdown.
> > 
> > We repeat the same with completely written, completely unwritten and completely
> > empty file to ensure these cases are not torn either.  Finally, we have a
> > similar test for append atomic writes
> > 
> > Suggested-by: Ritesh Harjani (IBM)<ritesh.list@xxxxxxxxx>
> > Signed-off-by: Ojaswin Mujoo<ojaswin@xxxxxxxxxxxxx>
> 
> this seems to work ok for xfs, as I get data verify errors when I remove the
> -A arg to xfs_io when doing the atomic writes.
> 
> But I see this (always):
> 
> @@ -1,2 +1,83 @@
>  QA output created by 1230
> +/home/opc/xfstests-dev/tests/generic/1230: line 13:
> _require_scratch_write_atomic_multi_fsblock: command not found
Hi John,

I missed mentioning that these patches are based on [1] which provides
this command.

[1] https://lore.kernel.org/fstests/20250626002735.22827-1-catherine.hoang@xxxxxxxxxx/T/#t

> +/home/opc/xfstests-dev/tests/generic/1230: line 149: kill: (535173) - No
> such process

Hmm so we follow the flow like:

1. spawn a thread A that does mixed atomic writes in bg
2. sleep 0.2s
3. shutdown and kill A

Seems like in your case, the disk maybe fast enough to actually finish
the task within the 0.2s we sleep for. 

I'll try to tune this better or see if we can just remove the sleep. In
the meantime, if you can share the seqres.full and out.bad file for this run
I'll be able to confirm if my analysis is correct.

Regards,
ojaswin

> any idea (apart from _require_scratch_write_atomic_multi_fsblock)?




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux