On Thu, Nov 02, 2023 at 06:06:10PM +0530, Chandan Babu R wrote:
> Hi,
>
> generic/311 consistently fails when executing on a kernel built from
> next-20231102.
>
> The following is the fstests config file that was used during testing.
>
> export FSTYP=xfs
>
> export TEST_DEV=/dev/loop0
> export TEST_DIR=/mnt/test
> export TEST_LOGDEV=/dev/loop2
>
> export SCRATCH_DEV=/dev/loop1
> export SCRATCH_MNT=/mnt/scratch
> export SCRATCH_LOGDEV=/dev/loop3
Thanks for the report. So dm flakey sets up:
/dev/dm-0 over /dev/loop0
/dev/dm-1 over /dev/loop2
and then we mount an xfs filesystem with:
/dev/loop2 as logdev and /dev/loop0 as the main device.
So on current kernels what happens is that if you freeze the main
device you end up:
bdev_freeze(dm-0)
-> get_super(dm-0) # finds xfs sb
-> freeze_super(sb)
if you also freeze the log device afterwards via:
bdev_freeze(dm-1)
-> get_super(dm-1) # doesn't find xfs sb because freezing only works for
# main device
What's currently in -next allows you to roughly do the following:
bdev_freeze(dm-0)
-> fs_bdev_freeze(dm-0->sb)
-> freeze_super(dm-0->sb) # returns 0
bdev_freeze(dm-1)
-> fs_bdev_freeze(dm-1->sb)
-> freeze_super(dm-1->sb) # returns -EBUSY
So you'll see EBUSY because the superblock was already frozen when the
main block device was frozen. I was somewhat expecting that we may run
into such issues.
I think we just need to figure out what we want to do in cases the
superblock is frozen via multiple devices. It would probably be correct
to keep it frozen as long as any of the devices is frozen?
