On Mon, Feb 17, 2020 at 5:36 AM Marcos Paulo de Souza <marcos@xxxxxxxxxxxxx> wrote: > > From: Marcos Paulo de Souza <mpdesouza@xxxxxxxx> > > As seem in this issue[1], this test can fail from time to time. The > issue happens when a mount is issued before the new device is processed > by systemd-udevd, as we can see by the og bellow: > > [ 2346.028809] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 1 transid 6 /dev/loop10 scanned by systemd-udevd (3418) > [ 2346.265401] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing > [ 2346.272474] BTRFS info (device loop10): disk space caching is enabled > [ 2346.277472] BTRFS info (device loop10): has skinny extents > [ 2346.281840] BTRFS info (device loop10): flagging fs with big metadata feature > [ 2346.308428] BTRFS error (device loop10): devid 2 uuid cde07de6-db7e-4b34-909e-d3db6e7c0b06 is missing > [ 2346.315363] BTRFS error (device loop10): failed to read the system array: -2 > [ 2346.329887] BTRFS error (device loop10): open_ctree failed > failed: mount /dev/loop10 /home/marcos/git/suse/btrfs-progs/tests//mnt > test failed for case 034-metadata-uuid > make: *** [Makefile:401: test-misc] Error 1 > [ 2346.666865] BTRFS: device fsid 593e23af-a7e6-4360-b16a-229f415de697 devid 2 transid 5 /dev/loop11 scanned by systemd-udevd (3422) > [ 2346.853233] BTRFS: device fsid 1c2debeb-e829-4d6b-84df-aa7c5d246fd5 devid 1 transid 7 /dev/loop6 scanned by systemd-udevd (3418) > > A few moments after the test failed systemd-udevd processed the new > device (registered the new device under btrfs). This can be > tested by executing a mount after the test failed, resulting in a > successful mount: > > mount /dev/loop10 /mnt > [ 2398.955254] BTRFS info (device loop10): found metadata UUID change in progress flag, clearing > [ 2398.959416] BTRFS info (device loop10): disk space caching is enabled > [ 2398.962483] BTRFS info (device loop10): has skinny extents > [ 2398.965070] BTRFS info (device loop10): flagging fs with big metadata feature > [ 2399.012617] BTRFS info (device loop10): enabling ssd optimizations > [ 2399.022375] BTRFS info (device loop10): checking UUID tree > > This problem can be avoided is we execute "udevadm settle" before the > mount is executed. > > [1]: https://github.com/kdave/btrfs-progs/issues/192 > > Signed-off-by: Marcos Paulo de Souza <mpdesouza@xxxxxxxx> Yes, as Nikolay said, your fix in udevd way is more graceful than mine. So Reviewed-by: Su Yue <Damenly_Su@xxxxxxx> > --- > tests/misc-tests/034-metadata-uuid/test.sh | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tests/misc-tests/034-metadata-uuid/test.sh b/tests/misc-tests/034-metadata-uuid/test.sh > index 6ac55b1c..9791285b 100755 > --- a/tests/misc-tests/034-metadata-uuid/test.sh > +++ b/tests/misc-tests/034-metadata-uuid/test.sh > @@ -6,6 +6,7 @@ check_prereq mkfs.btrfs > check_prereq btrfs > check_prereq btrfstune > check_prereq btrfs-image > +check_global_prereq udevadm > > setup_root_helper > prepare_test_dev > @@ -172,6 +173,8 @@ failure_recovery() { > loop1=$(run_check_stdout $SUDO_HELPER losetup --find --show "$image1") > loop2=$(run_check_stdout $SUDO_HELPER losetup --find --show "$image2") > > + run_check $SUDO_HELPER udevadm settle > + > # Mount and unmount, on trans commit all disks should be consistent > run_check $SUDO_HELPER mount "$loop1" "$TEST_MNT" > run_check $SUDO_HELPER umount "$TEST_MNT" > -- > 2.25.0 >
