| Message ID | af8ae1adbb827a1de806af25a63622b19d6765de.1692018849.git.anand.jain@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs-progs: recover from failed metadata_uuid | expand |
On Mon, Aug 14, 2023 at 11:28:12PM +0800, Anand Jain wrote: > The misc-test/034-metadata_uuid test case, has four sets of disk images to > simulate failed writes during btrfstune -m|M operations. As of now, this > tests kernel only. Update the test case to verify btrfstune -m|M's > capacity to recover from the same scenarios. > > Signed-off-by: Anand Jain <anand.jain@oracle.com> > --- > tests/misc-tests/034-metadata-uuid/test.sh | 70 ++++++++++++++++------ > 1 file changed, 53 insertions(+), 17 deletions(-) > > diff --git a/tests/misc-tests/034-metadata-uuid/test.sh b/tests/misc-tests/034-metadata-uuid/test.sh > index f2daa76304de..6aa1cdcb47ae 100755 > --- a/tests/misc-tests/034-metadata-uuid/test.sh > +++ b/tests/misc-tests/034-metadata-uuid/test.sh > @@ -195,13 +195,42 @@ check_multi_fsid_unchanged() { > check_flag_cleared "$1" "$2" > } > > -failure_recovery() { > +failure_recovery_progs() { > + local image1 > + local image2 > + local loop1 > + local loop2 > + local devcount > + > + image1=$(extract_image "$1") > + image2=$(extract_image "$2") > + 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 > + > + # Scan to make sure btrfs detects both devices before trying to mount > + #run_check "$TOP/btrfstune" -m --noscan --device="$loop1" "$loop2" Why is this line here? It looks like a valid command line and then it's confusing. If there's some condition like that you want to require scanning then put it to comment and explain it, e.g. "we can't use --noscan here because ...". > + run_check "$TOP/btrfstune" -m "$loop2" > + > + # perform any specific check > + "$3" "$loop1" "$loop2" > + > + # cleanup > + run_check $SUDO_HELPER losetup -d "$loop1" > + run_check $SUDO_HELPER losetup -d "$loop2" > + rm -f -- "$image1" "$image2" > +}
On 24/08/2023 04:10, David Sterba wrote: > On Mon, Aug 14, 2023 at 11:28:12PM +0800, Anand Jain wrote: >> The misc-test/034-metadata_uuid test case, has four sets of disk images to >> simulate failed writes during btrfstune -m|M operations. As of now, this >> tests kernel only. Update the test case to verify btrfstune -m|M's >> capacity to recover from the same scenarios. >> >> Signed-off-by: Anand Jain <anand.jain@oracle.com> >> --- >> tests/misc-tests/034-metadata-uuid/test.sh | 70 ++++++++++++++++------ >> 1 file changed, 53 insertions(+), 17 deletions(-) >> >> diff --git a/tests/misc-tests/034-metadata-uuid/test.sh b/tests/misc-tests/034-metadata-uuid/test.sh >> index f2daa76304de..6aa1cdcb47ae 100755 >> --- a/tests/misc-tests/034-metadata-uuid/test.sh >> +++ b/tests/misc-tests/034-metadata-uuid/test.sh >> @@ -195,13 +195,42 @@ check_multi_fsid_unchanged() { >> check_flag_cleared "$1" "$2" >> } >> >> -failure_recovery() { >> +failure_recovery_progs() { >> + local image1 >> + local image2 >> + local loop1 >> + local loop2 >> + local devcount >> + >> + image1=$(extract_image "$1") >> + image2=$(extract_image "$2") >> + 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 >> + >> + # Scan to make sure btrfs detects both devices before trying to mount >> + #run_check "$TOP/btrfstune" -m --noscan --device="$loop1" "$loop2" > > Why is this line here? It looks like a valid command line and then it's > confusing. If there's some condition like that you want to require > scanning then put it to comment and explain it, e.g. "we can't use > --noscan here because ...". My bad. Those two comment lines shouldn't be here, and it's okay to remove them. It was taken from the patchset that added the --device and --noscan options. I'll clean it up. Thanks, Anand >> + run_check "$TOP/btrfstune" -m "$loop2" >> + >> + # perform any specific check >> + "$3" "$loop1" "$loop2" >> + >> + # cleanup >> + run_check $SUDO_HELPER losetup -d "$loop1" >> + run_check $SUDO_HELPER losetup -d "$loop2" >> + rm -f -- "$image1" "$image2" >> +}
diff --git a/tests/misc-tests/034-metadata-uuid/test.sh b/tests/misc-tests/034-metadata-uuid/test.sh index f2daa76304de..6aa1cdcb47ae 100755 --- a/tests/misc-tests/034-metadata-uuid/test.sh +++ b/tests/misc-tests/034-metadata-uuid/test.sh @@ -195,13 +195,42 @@ check_multi_fsid_unchanged() { check_flag_cleared "$1" "$2" } -failure_recovery() { +failure_recovery_progs() { + local image1 + local image2 + local loop1 + local loop2 + local devcount + + image1=$(extract_image "$1") + image2=$(extract_image "$2") + 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 + + # Scan to make sure btrfs detects both devices before trying to mount + #run_check "$TOP/btrfstune" -m --noscan --device="$loop1" "$loop2" + run_check "$TOP/btrfstune" -m "$loop2" + + # perform any specific check + "$3" "$loop1" "$loop2" + + # cleanup + run_check $SUDO_HELPER losetup -d "$loop1" + run_check $SUDO_HELPER losetup -d "$loop2" + rm -f -- "$image1" "$image2" +} + +failure_recovery_kernel() { local image1 local image2 local loop1 local loop2 local devcount + reload_btrfs + image1=$(extract_image "$1") image2=$(extract_image "$2") loop1=$(run_check_stdout $SUDO_HELPER losetup --find --show "$image1") @@ -226,47 +255,55 @@ failure_recovery() { rm -f -- "$image1" "$image2" } +failure_recovery() { + failure_recovery_progs $@ + failure_recovery_kernel $@ +} + reload_btrfs() { run_check $SUDO_HELPER rmmod btrfs run_check $SUDO_HELPER modprobe btrfs } -# for full coverage we need btrfs to actually be a module -modinfo btrfs > /dev/null 2>&1 || _not_run "btrfs must be a module" -run_mayfail $SUDO_HELPER modprobe -r btrfs || _not_run "btrfs must be unloadable" -run_mayfail $SUDO_HELPER modprobe btrfs || _not_run "loading btrfs module failed" +test_progs() { + run_check_mkfs_test_dev + check_btrfstune + + run_check_mkfs_test_dev + check_dump_super_output -run_check_mkfs_test_dev -check_btrfstune + run_check_mkfs_test_dev + check_image_restore +} + +check_kernel_reloadable() { + # for full coverage we need btrfs to actually be a module + modinfo btrfs > /dev/null 2>&1 || _not_run "btrfs must be a module" + run_mayfail $SUDO_HELPER modprobe -r btrfs || _not_run "btrfs must be unloadable" + run_mayfail $SUDO_HELPER modprobe btrfs || _not_run "loading btrfs module failed" +} -run_check_mkfs_test_dev -check_dump_super_output +check_kernel_reloadable -run_check_mkfs_test_dev -check_image_restore +test_progs # disk1 is an image which has no metadata uuid flags set and disk2 is part of # the same fs but has the in-progress flag set. Test that whicever is scanned # first will result in consistent filesystem. failure_recovery "./disk1.raw.xz" "./disk2.raw.xz" check_inprogress_flag -reload_btrfs failure_recovery "./disk2.raw.xz" "./disk1.raw.xz" check_inprogress_flag # disk4 contains an image in with the in-progress flag set and disk 3 is part # of the same filesystem but has both METADATA_UUID incompat and a new # metadata uuid set. So disk 3 must always take precedence -reload_btrfs failure_recovery "./disk3.raw.xz" "./disk4.raw.xz" check_completed -reload_btrfs failure_recovery "./disk4.raw.xz" "./disk3.raw.xz" check_completed # disk5 contains an image which has undergone a successful fsid change more # than once, disk6 on the other hand is member of the same filesystem but # hasn't completed its last change. Thus it has both the FSID_CHANGING flag set # and METADATA_UUID flag set. -reload_btrfs failure_recovery "./disk5.raw.xz" "./disk6.raw.xz" check_multi_fsid_change -reload_btrfs failure_recovery "./disk6.raw.xz" "./disk5.raw.xz" check_multi_fsid_change # disk7 contains an image which has undergone a successful fsid change once to @@ -275,5 +312,4 @@ failure_recovery "./disk6.raw.xz" "./disk5.raw.xz" check_multi_fsid_change # during the process change. So disk 7 looks as if it never underwent fsid change # and disk 8 has FSID_CHANGING_FLAG and METADATA_UUID but is stale. failure_recovery "./disk7.raw.xz" "./disk8.raw.xz" check_multi_fsid_unchanged -reload_btrfs failure_recovery "./disk8.raw.xz" "./disk7.raw.xz" check_multi_fsid_unchanged
The misc-test/034-metadata_uuid test case, has four sets of disk images to simulate failed writes during btrfstune -m|M operations. As of now, this tests kernel only. Update the test case to verify btrfstune -m|M's capacity to recover from the same scenarios. Signed-off-by: Anand Jain <anand.jain@oracle.com> --- tests/misc-tests/034-metadata-uuid/test.sh | 70 ++++++++++++++++------ 1 file changed, 53 insertions(+), 17 deletions(-)