| Message ID | 20151110003002.GK15575@wotan.suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Mark, On Mon, Nov 09, 2015 at 04:30:02PM -0800, Mark Fasheh wrote: > Btrfsprogs now has 'subvolume sync' which will wait until deleted subvolumes > are cleaned from disk. > > Signed-off-by: Mark Fasheh <mfasheh@suse.de> > --- > tests/btrfs/104 | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/tests/btrfs/104 b/tests/btrfs/104 > index 80161a3..6848b87 100644 > --- a/tests/btrfs/104 > +++ b/tests/btrfs/104 > @@ -146,11 +146,9 @@ _scratch_remount > # referenced above. > _run_btrfs_util_prog subvolume delete $SCRATCH_MNT/snap1 > > -# There is no way from userspace to force btrfs_drop_snapshot to run > -# at a given time (even via mount/unmount). We must wait for it to > -# start and complete. This is the shortest time on my tests systems I > -# have found which always allows drop_snapshot to run to completion. > -sleep 45 > +# Subvol delete is a delayed operation, wait for it to complete before > +# unmounting. > +_run_btrfs_util_prog subvolume sync $SCRATCH_MNT Won't that now fail on systems without the "subvolume sync" command because of the hidden use of _run_check in _run_btrfs_util_prog? i.e. doesn't it need to do something like: $BTRFS_UTIL_PROG subvolume sync $SCRATCH_MNT if [ $? -ne 0 ]; then sleep 45 fi So that it works on all versions of the btrfs utility? Cheers, Dave.
Hi David, On Thu, Nov 12, 2015 at 11:49:17AM +1100, Dave Chinner wrote: > > +# Subvol delete is a delayed operation, wait for it to complete before > > +# unmounting. > > +_run_btrfs_util_prog subvolume sync $SCRATCH_MNT > > Won't that now fail on systems without the "subvolume sync" > command because of the hidden use of _run_check in > _run_btrfs_util_prog? i.e. doesn't it need to do something like: > > $BTRFS_UTIL_PROG subvolume sync $SCRATCH_MNT > if [ $? -ne 0 ]; then > sleep 45 > fi > > So that it works on all versions of the btrfs utility? You know, you are probably right and I should have known because we already talked about _run_check hiding errors! I'll fix that up and send out a new patch once I've tested the change. Thanks, --Mark -- Mark Fasheh -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/tests/btrfs/104 b/tests/btrfs/104 index 80161a3..6848b87 100644 --- a/tests/btrfs/104 +++ b/tests/btrfs/104 @@ -146,11 +146,9 @@ _scratch_remount # referenced above. _run_btrfs_util_prog subvolume delete $SCRATCH_MNT/snap1 -# There is no way from userspace to force btrfs_drop_snapshot to run -# at a given time (even via mount/unmount). We must wait for it to -# start and complete. This is the shortest time on my tests systems I -# have found which always allows drop_snapshot to run to completion. -sleep 45 +# Subvol delete is a delayed operation, wait for it to complete before +# unmounting. +_run_btrfs_util_prog subvolume sync $SCRATCH_MNT _scratch_unmount
Btrfsprogs now has 'subvolume sync' which will wait until deleted subvolumes are cleaned from disk. Signed-off-by: Mark Fasheh <mfasheh@suse.de> --- tests/btrfs/104 | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)