linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Koen De Wit <koen.de.wit@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <esandeen@redhat.com>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v3] xfstests: btrfs/316: cross-subvolume sparse copy
Date: Wed, 03 Jul 2013 12:02:52 +0200	[thread overview]
Message-ID: <51D3F6CC.2040709@oracle.com> (raw)
In-Reply-To: <20130703063724.GK14996@dastard>

On 07/03/2013 08:37 AM, Dave Chinner wrote:

> On Tue, Jul 02, 2013 at 11:51:21AM -0400, Eric Sandeen wrote:
>> On Jul 2, 2013, at 10:28 AM, Koen De Wit <koen.de.wit@oracle.com>
>> wrote:
>>
>>> Dave,
>>>
>>> Thanks for the review. I will clean up the commit message and do
>>> a full mail-to-myself-and-test-patch round trip to avoid errors
>>> like the wrong test numbers in the golden output. I'm sorry for
>>> this.
>>>
>>> About cutting out file names from the output. I did this in the
>>> first version of the patch:
>>>
>>>       md5sum $TESTDIR1/$F | $AWK_PROG 'END {print $1}'
>>>
>>> but Eric Sandeen suggested to include them in order to provide
>>> more context in the output. (See
>>> http://oss.sgi.com/archives/xfs/2013-03/msg00231.html and
>>> http://oss.sgi.com/archives/xfs/2013-03/msg00220.html) That
>>> sounds like a good idea to me, it makes debugging failures
>>> easier. Whose opinion should I follow?
>>>
>> Heh sorry.  IMHO maybe a middle ground; not bare md5sum but show
>> only the base name?  In the end up to you; it seems Dave and I
>> have different opinions on this.  :)
> 
> I was just going by current xfstests convention. i.e, in common/rc:
> 
> # Prints the md5 checksum of a given file
> _md5_checksum()
> {
>         md5sum $1 | cut -d ' ' -f1
> }
> 
> Which is used by all the hole punch tests and generic/311.


That's true, but these tests generate other context information in the
output. They don't just print a bunch of checksums.

For example, the output of generic/255 looks like:

        1. into a hole
   daa100df6e6711906b61c9ab5aa16032
        2. into allocated space
   0: [0..7]: extent
   1: [8..23]: hole
   2: [24..39]: extent
   cc58a7417c2d7763adc45b6fcd3fa024
        3. into unwritten space
   0: [0..7]: extent
   1: [8..23]: hole
   2: [24..39]: extent
   daa100df6e6711906b61c9ab5aa16032
   (...)

The output of generic/311 looks like:

   Running test 1 buffered, normal suspend
   Random seed is 1
   ee6103415276cde95544b11b2675f132
   ee6103415276cde95544b11b2675f132
   Running test 1 direct, normal suspend
   Random seed is 1
   ee6103415276cde95544b11b2675f132
   ee6103415276cde95544b11b2675f132
   (...)

> Make of that what you will, but I'd prefer to see consistency of
> implementation across tests... ;)


Do I agree if I change _checksum_files() to:

   _checksum_files() {
       for F in file1 file2 file3
       do
           echo "$F:"
           for D in $TESTDIR1 $SCRATCH_MNT $SUBVOL2
           do
               _md5_checksum $D/$F
           done
       done
   }

It produces this in the output:

   (...)
   file1:
   00d620f69f30327f0f8946b95c12de44
   e09c80c42fda55f9d992e59ca6b3307d
   e09c80c42fda55f9d992e59ca6b3307d
   file2:
   d7402b46310fbbfbc5e466b1dccb043b
   d7402b46310fbbfbc5e466b1dccb043b
   917619ae44b38bb9968af261c3c45440
   file3:
   5a95800e4c04b11117aa4e4de057721f
   b9f275cd638cb784c9e61def94c622a8
   5a95800e4c04b11117aa4e4de057721f
   (...)


Thanks,
Koen.

  reply	other threads:[~2013-07-03 10:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02  9:27 [PATCH v3] xfstests: btrfs/316: cross-subvolume sparse copy Koen De Wit
2013-07-02 10:15 ` Dave Chinner
2013-07-02 14:27   ` Koen De Wit
2013-07-02 15:51     ` Eric Sandeen
2013-07-03  6:37       ` Dave Chinner
2013-07-03 10:02         ` Koen De Wit [this message]
2013-07-03 10:17           ` 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=51D3F6CC.2040709@oracle.com \
    --to=koen.de.wit@oracle.com \
    --cc=david@fromorbit.com \
    --cc=esandeen@redhat.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 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).