From: Jan Schmidt <list.xfs@jan-o-sch.net>
To: Arne Jansen <sensille@gmx.net>
Cc: Eric Sandeen <sandeen@redhat.com>,
Dave Chinner <david@fromorbit.com>,
sbehrens@giantdisaster.de, linux-btrfs@vger.kernel.org,
xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests btrfs/314: test send / receive
Date: Fri, 07 Jun 2013 16:53:52 +0200 [thread overview]
Message-ID: <51B1F400.1040107@jan-o-sch.net> (raw)
In-Reply-To: <51B1F37D.1060005@gmx.net>
On Fri, June 07, 2013 at 16:51 (+0200), Arne Jansen wrote:
> On 07.06.2013 16:50, Eric Sandeen wrote:
>> On 6/7/13 5:29 AM, Dave Chinner wrote:
>>> On Fri, Jun 07, 2013 at 09:18:58AM +0200, Jan Schmidt wrote:
>>>> (cc Arne for far-progs discussion)
>>>>
>>>> On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen wrote:
>>>>> On 6/6/13 10:20 AM, Jan Schmidt wrote:
>>>>>> Basic send / receive functionality test for btrfs. Requires current
>>>>>> version of fsstress built (-x support). Relies on fssum tool, which is
>>>>>> not part of the test suite but can skip the test if it is missing.
>>>>>>
>>>>>> Signed-off-by: Jan Schmidt <list.xfs@jan-o-sch.net>
>>>>>
>>>>> w/o commenting on the test itself, I'm a little uneasy about requiring
>>>>> some external, not-widely-installed tool for this to run. The fear is
>>>>> that it won't be run as often as it could/should be.
>>>>
>>>> The main purpose is to have it run by developers changing something around btrfs
>>>> send / receive and probably the backref walker (while there exists a separate
>>>> test not requiring fssum for backrefs). I think we can get them to install fssum.
>>>
>>> There's no point in having tests that require you to go find
>>> something else before the tests can be run. That's been tried
>>> before, and it doesn't work - the test just won't get run by
>>> the majority of people who run xfstests.
>>>
>>>>> Could the same test be done w/o fssum, or should we maybe put a copy
>>>>> of fssum into xfstests/src/fssum.c ?
>>>>
>>>> I don't know any adequate replacement for fssum in this case. The purpose is to
>>>> build a checksum for a whole file system tree, including data and partly metadata.
>>>>
>>>> I don't feel like copying fssum from far-progs into xfstests, though it probably
>>>> won't hurt much. However, I cannot promise we won't make changes to it for
>>>> far-progs, probably creating two incompatible versions of fssum in the wild. Arne?
>>>>
>>>>> Or does fssum exist in any standard distro package?
>>>>
>>>> It doesn't. Perhaps Josef can hurry and make a Fedora package for it, if that
>>>> prevents a separate copy to xfstests :-)
>>>
>>> No, it doesn't. Packages would be needed for debian, suse, SLES,
>>> RHEL, etc for that to be a useful method of distribution. Just dump
>>> a snapshot of the utility in the xfstests src dir so we don't have
>>> to care about distribution issues...
>>
>> Yup I agree with this, if it's not widely available or replaceable by more
>> common tools, let's just put a snapshot in xfstests.
>
> I'm fine with that, too.
To prevent more agreement mails: I'll send a v2 including fssum.c, but probably
not today.
-Jan
> -Arne
>
>>
>> -Eric
>>
>>> Cheers,
>>>
>>> Dave.
>>>
>>
>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Schmidt <list.xfs@jan-o-sch.net>
To: Arne Jansen <sensille@gmx.net>
Cc: Eric Sandeen <sandeen@redhat.com>,
linux-btrfs@vger.kernel.org, sbehrens@giantdisaster.de,
xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests btrfs/314: test send / receive
Date: Fri, 07 Jun 2013 16:53:52 +0200 [thread overview]
Message-ID: <51B1F400.1040107@jan-o-sch.net> (raw)
In-Reply-To: <51B1F37D.1060005@gmx.net>
On Fri, June 07, 2013 at 16:51 (+0200), Arne Jansen wrote:
> On 07.06.2013 16:50, Eric Sandeen wrote:
>> On 6/7/13 5:29 AM, Dave Chinner wrote:
>>> On Fri, Jun 07, 2013 at 09:18:58AM +0200, Jan Schmidt wrote:
>>>> (cc Arne for far-progs discussion)
>>>>
>>>> On Thu, June 06, 2013 at 19:54 (+0200), Eric Sandeen wrote:
>>>>> On 6/6/13 10:20 AM, Jan Schmidt wrote:
>>>>>> Basic send / receive functionality test for btrfs. Requires current
>>>>>> version of fsstress built (-x support). Relies on fssum tool, which is
>>>>>> not part of the test suite but can skip the test if it is missing.
>>>>>>
>>>>>> Signed-off-by: Jan Schmidt <list.xfs@jan-o-sch.net>
>>>>>
>>>>> w/o commenting on the test itself, I'm a little uneasy about requiring
>>>>> some external, not-widely-installed tool for this to run. The fear is
>>>>> that it won't be run as often as it could/should be.
>>>>
>>>> The main purpose is to have it run by developers changing something around btrfs
>>>> send / receive and probably the backref walker (while there exists a separate
>>>> test not requiring fssum for backrefs). I think we can get them to install fssum.
>>>
>>> There's no point in having tests that require you to go find
>>> something else before the tests can be run. That's been tried
>>> before, and it doesn't work - the test just won't get run by
>>> the majority of people who run xfstests.
>>>
>>>>> Could the same test be done w/o fssum, or should we maybe put a copy
>>>>> of fssum into xfstests/src/fssum.c ?
>>>>
>>>> I don't know any adequate replacement for fssum in this case. The purpose is to
>>>> build a checksum for a whole file system tree, including data and partly metadata.
>>>>
>>>> I don't feel like copying fssum from far-progs into xfstests, though it probably
>>>> won't hurt much. However, I cannot promise we won't make changes to it for
>>>> far-progs, probably creating two incompatible versions of fssum in the wild. Arne?
>>>>
>>>>> Or does fssum exist in any standard distro package?
>>>>
>>>> It doesn't. Perhaps Josef can hurry and make a Fedora package for it, if that
>>>> prevents a separate copy to xfstests :-)
>>>
>>> No, it doesn't. Packages would be needed for debian, suse, SLES,
>>> RHEL, etc for that to be a useful method of distribution. Just dump
>>> a snapshot of the utility in the xfstests src dir so we don't have
>>> to care about distribution issues...
>>
>> Yup I agree with this, if it's not widely available or replaceable by more
>> common tools, let's just put a snapshot in xfstests.
>
> I'm fine with that, too.
To prevent more agreement mails: I'll send a v2 including fssum.c, but probably
not today.
-Jan
> -Arne
>
>>
>> -Eric
>>
>>> Cheers,
>>>
>>> Dave.
>>>
>>
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-06-07 14:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 15:20 [PATCH] xfstests btrfs/314: test send / receive Jan Schmidt
2013-06-06 15:20 ` Jan Schmidt
2013-06-06 17:49 ` Josef Bacik
2013-06-06 17:49 ` Josef Bacik
2013-06-06 17:54 ` Eric Sandeen
2013-06-06 17:54 ` Eric Sandeen
2013-06-07 7:18 ` Jan Schmidt
2013-06-07 7:18 ` Jan Schmidt
2013-06-07 10:29 ` Dave Chinner
2013-06-07 10:29 ` Dave Chinner
2013-06-07 14:50 ` Eric Sandeen
2013-06-07 14:50 ` Eric Sandeen
2013-06-07 14:51 ` Arne Jansen
2013-06-07 14:51 ` Arne Jansen
2013-06-07 14:53 ` Jan Schmidt [this message]
2013-06-07 14:53 ` Jan Schmidt
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=51B1F400.1040107@jan-o-sch.net \
--to=list.xfs@jan-o-sch.net \
--cc=david@fromorbit.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sbehrens@giantdisaster.de \
--cc=sensille@gmx.net \
--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.