All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Josef Bacik <jbacik@fusionio.com>
Cc: xfs@oss.sgi.com, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] xfstests: btrfs 308: regression test for btrfs send
Date: Tue, 21 May 2013 10:33:26 +1000	[thread overview]
Message-ID: <20130521003326.GJ24543@dastard> (raw)
In-Reply-To: <1369070434-20852-1-git-send-email-jbacik@fusionio.com>

On Mon, May 20, 2013 at 01:20:34PM -0400, Josef Bacik wrote:
> I'm not sure how the numbering is supposed to work now that we've split
> everything out so I'm just going with the next number in the directory.  This is
> a regression test for btrfs send, we had a problem where we'd try to send a file
> that had been deleted in the source snapshot.  This is just to make sure we
> don't have the same problem in the future.  Thanks,

You are holding open an unlinked file? You want to use
src/multi_open_unlink, then.

/*
 * multi_open_unlink path_prefix num_files sleep_time
 * e.g.
 *   $ multi_open_unlink file 100 60
 *   Creates 100 files: file.1, file.2, ..., file.100
 *   unlinks them all but doesn't close them all until after 60 seconds.
 */

If you need to hold open existing files, add support for that into
multi_open_unlink.c (i.e. allow it to ignore EEXIST when trying to
create files).

> +# need this so that tail doesn't error out racing with the rm
> +sleep 1
> +rm -f $SCRATCH_MNT/foo
> +$BTRFS_UTIL_PROG subvol snap -r $SCRATCH_MNT $SCRATCH_MNT/snap1 > /dev/null 2>&1
> +$BTRFS_UTIL_PROG send -f /dev/null -p $SCRATCH_MNT/snap $SCRATCH_MNT/snap1 >/dev/null 2>&1

I'd send this output to $seqres.full, so if the test fails there's
debug output to look at...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Josef Bacik <jbacik@fusionio.com>
Cc: linux-btrfs@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: btrfs 308: regression test for btrfs send
Date: Tue, 21 May 2013 10:33:26 +1000	[thread overview]
Message-ID: <20130521003326.GJ24543@dastard> (raw)
In-Reply-To: <1369070434-20852-1-git-send-email-jbacik@fusionio.com>

On Mon, May 20, 2013 at 01:20:34PM -0400, Josef Bacik wrote:
> I'm not sure how the numbering is supposed to work now that we've split
> everything out so I'm just going with the next number in the directory.  This is
> a regression test for btrfs send, we had a problem where we'd try to send a file
> that had been deleted in the source snapshot.  This is just to make sure we
> don't have the same problem in the future.  Thanks,

You are holding open an unlinked file? You want to use
src/multi_open_unlink, then.

/*
 * multi_open_unlink path_prefix num_files sleep_time
 * e.g.
 *   $ multi_open_unlink file 100 60
 *   Creates 100 files: file.1, file.2, ..., file.100
 *   unlinks them all but doesn't close them all until after 60 seconds.
 */

If you need to hold open existing files, add support for that into
multi_open_unlink.c (i.e. allow it to ignore EEXIST when trying to
create files).

> +# need this so that tail doesn't error out racing with the rm
> +sleep 1
> +rm -f $SCRATCH_MNT/foo
> +$BTRFS_UTIL_PROG subvol snap -r $SCRATCH_MNT $SCRATCH_MNT/snap1 > /dev/null 2>&1
> +$BTRFS_UTIL_PROG send -f /dev/null -p $SCRATCH_MNT/snap $SCRATCH_MNT/snap1 >/dev/null 2>&1

I'd send this output to $seqres.full, so if the test fails there's
debug output to look at...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-05-21  0:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-20 17:20 [PATCH] xfstests: btrfs 308: regression test for btrfs send Josef Bacik
2013-05-20 17:20 ` Josef Bacik
2013-05-21  0:33 ` Dave Chinner [this message]
2013-05-21  0:33   ` Dave Chinner

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=20130521003326.GJ24543@dastard \
    --to=david@fromorbit.com \
    --cc=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /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.