On 2020/2/7 下午8:01, Anand Jain wrote: > On some systems btrfs/179 fails as the check finds that there is > difference in the qgroup counts. > > By the async nature of qgroup tree scan, the latest qgroup counts at the > time of umount might not be upto date, Yes, so far so good. > if it isn't then the check will > report the difference in count. The difference in qgroup counts are anyway > updated in the following mount, so it is not a real issue that this test > case is trying to verify. No problem either. > So make sure the qgroup counts are updated > before unmount happens and make the check happy. But the solution doesn't look correct to me. We should either make btrfs-check to handle such half-dropped case better, or find a way to wait for all subvolume drop to be finished in test case. Papering the test by rescan is not a good idea at all. If one day we really hit some qgroup accounting problem, this papering way could hugely reduce the coverage. Thanks, Qu > > Signed-off-by: Anand Jain <anand.jain@xxxxxxxxxx> > --- > tests/btrfs/179 | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/tests/btrfs/179 b/tests/btrfs/179 > index 4a24ea419a7e..74e91841eaa6 100755 > --- a/tests/btrfs/179 > +++ b/tests/btrfs/179 > @@ -109,6 +109,14 @@ wait $snapshot_pid > kill $delete_pid > wait $delete_pid > > +# By the async nature of qgroup tree scan, the latest qgroup counts at the time > +# of umount might not be upto date, if it isn't then the check will report the > +# difference in count. The difference in qgroup counts are anyway updated in the > +# following mount, so it is not a real issue that this test case is trying to > +# verify. So make sure the qgroup counts are updated before unmount happens. > + > +$BTRFS_UTIL_PROG quota rescan -w $SCRATCH_MNT >> $seqres.full > + > # success, all done > echo "Silence is golden" > >
Attachment:
signature.asc
Description: OpenPGP digital signature
