From: Dave Chinner <david@fromorbit.com>
To: Wang Shilong <wangshilong1991@gmail.com>
Cc: xfs@oss.sgi.com, linux-btrfs@vger.kernel.org, jbacik@fb.com
Subject: Re: [PATCH v3] Btrfs: add regression test for running snapshot and send concurrently
Date: Fri, 7 Feb 2014 15:41:53 +1100 [thread overview]
Message-ID: <20140207044153.GF13647@dastard> (raw)
In-Reply-To: <D32F9438-DA80-41AF-9247-A81E6EC90497@gmail.com>
On Fri, Feb 07, 2014 at 12:18:31PM +0800, Wang Shilong wrote:
>
> Hi Dave,
>
> > On Fri, Feb 07, 2014 at 12:10:08AM +0800, Wang Shilong wrote:
> >> +$BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT \
> >> + $SCRATCH_MNT/snap_1 >> $seqres.full 2>&1
> >> +
> >> +do_snapshots &
> >> +snapshots_pid=$!
> >> +
> >> +$BTRFS_UTIL_PROG send $SCRATCH_MNT/snap_1 > /dev/null 2>&1 || echo "btrfs send failed"
> >
> > Let's stop this anti-pattern before it takes hold.
> >
> > If there's output from the send command it should be
> > filtered and captured in the golden image. Hence any deviation
> > caused by errors is automatically flagged as an error.
> >
> > That's the whole point of using golden images for capturing errors -
> > you don't need to capture return values from binaries and it
> > guarantees that users are informed about failures through error
> > messages. IOWs:
> >
> > $BTRFS_UTIL_PROG send $SCRATCH_MNT/snap_1 | _btrfs_send_filter
> >
> > is what you should be doing here.
>
> I knew what you mean here, in fact, i did this on purpose.
Ok, then you need to explain why you did it on purpose with a comment.
It's just as important to explain the reason for doing something in
test code as it is in the kernel code. i.e. so when we are looking
at the test in 5 years time we know the reason for it being that
way.
> for this test failure, btrfs-prog did not output failure
> information from the beginning.
I have nothing good to say about that state of affairs, but...
> So to make older progs can also
> detect the test failure, i dropped into this way.
.. it's going to have to stay like it. Please insert an
appropriately sarcastic comment about the usefulness of a silent
send command here, because if I write it I'm going to offend lots of
people. :/
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2014-02-07 4:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-06 16:10 [PATCH v3] Btrfs: add regression test for running snapshot and send concurrently Wang Shilong
2014-02-06 22:43 ` Dave Chinner
2014-02-07 4:18 ` Wang Shilong
2014-02-07 4:41 ` Dave Chinner [this message]
2014-02-07 10:48 ` Wang Shilong
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=20140207044153.GF13647@dastard \
--to=david@fromorbit.com \
--cc=jbacik@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wangshilong1991@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).