All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Mark Fasheh <mfasheh@suse.de>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] btrfs/104: replace ugly sleep with subvol sync
Date: Thu, 12 Nov 2015 11:49:17 +1100	[thread overview]
Message-ID: <20151112004917.GQ19199@dastard> (raw)
In-Reply-To: <20151110003002.GK15575@wotan.suse.de>

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.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2015-11-12  0:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10  0:30 [PATCH] btrfs/104: replace ugly sleep with subvol sync Mark Fasheh
2015-11-12  0:49 ` Dave Chinner [this message]
2015-11-12 17:08   ` Mark Fasheh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151112004917.GQ19199@dastard \
    --to=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    --cc=mfasheh@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.