Re: [PATCH 2/9] fstests: add _mkfs_scratch_clone() helper

Zorro Lang
2026-03-14T17:04:31Z

On Wed, Mar 11, 2026 at 10:32:18AM +0800, Anand Jain wrote:
>
> > What about if ${#devs[@]} > 2 ?
>
> On purpose- so tests using _scratch_mkfs_sized_clone() don't
> pick a random higher number. If a test needs more than two
> devices, opens an opportunity to critically review this function.
> >> + fi
> >> +
> >> + case "$FSTYP" in
> >> + "btrfs")
> >> + _scratch_mkfs_sized $size
> >> + _scratch_mount
> >> + $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/sv1
> >> + _scratch_unmount
> >> + ;;
> >> + "xfs"|"ext4")
> >> + _scratch_mkfs_sized $size
> >> + ;;
> >> + *)
> >> + _notrun "fstests clone op unsupported for FS $FSTYP"
> >> + ;;
> >> + esac
> >> +
> >> + # clone SCRATCH_DEV devs[0] to devs[1].
> >> + dd if=$SCRATCH_DEV of=${devs[1]} bs=$size status=none count=1 || \
> >> + _fail "Clone failed"
> >
> > I'm wondering if we absolutely need to use SCRATCH_DEV_POOL for this test. Could we clone SCRATCH_DEV
> > to an image file instead? Or would it be feasible to simply run the test using two image files?
>
> Using a config file and testing directly on block devices lets
> us cover a wider range of devices.
>
> When I wrote this test case, I was also considering whether a
> serial-number–based mount without extra mount option, would be
> better in the kernel.
>
> The downside is that xfs/ext4 testers now need to use
> SCRATCH_DEV_POOL. Let me know what you prefer.

I'm concerned that testers from other filesystems might not be familiar
with SCRATCH_DEV_POOL, as it's typically not a requirement for their
testing. I'm not sure if they would be willing to configure and switch
to SCRATCH_DEV_POOL, just for these few test cases. If we can avoid making
the pool to be a hard requirement, it might be more user-friendly for other
fs list. Welcome feedback and review points from other filesystem mailing
lists :)

Thanks,
Zorro

>
>
>
>