All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Josef Bacik <jbacik@fusionio.com>
Cc: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs-progs: add make test framework
Date: Mon, 09 Sep 2013 14:07:43 -0500	[thread overview]
Message-ID: <522E1C7F.1010905@redhat.com> (raw)
In-Reply-To: <20130909171328.GA2446@localhost.localdomain>

On 9/9/13 12:13 PM, Josef Bacik wrote:
> On Mon, Sep 09, 2013 at 06:32:04PM +0200, David Sterba wrote:
>> On Fri, Sep 06, 2013 at 02:50:56PM -0400, Josef Bacik wrote:
>>> We need to start adding some sanity tests to btrfs-progs to make sure we aren't
>>> breaking things with our patches.  The most important of these tools is btrfsck.
>>> This patch gets things started by adding a basic btrfsck test that makes sure we
>>> can fix a corruption problem we know we can fix.  Thanks,
>>
>> That's great. I hope we're going to gather more tests so let's separate
>> them to more categories from the beginning (mkfs, options coverage,
>> corrupt-block, restore maybe, dunno what else).
>>
>> This makes it possible to do a quick run a subset of the tests (eg. mkfs
>> related) after a fix is committed.
>>
>>>  tests/bad-file-extent-bytenr.img |  Bin 0 -> 4096 bytes
>>>  tests/fsck-tests.sh              |   34 ++++++++++++++++++++++++++++++++++
>>
>> I suggest to put them into a subdirectory (eg.) 'fsck' and prefix the
>> images with numbers (just a sequence number).
> 
> I'm not prefixing with numbers, I want to make it easy to tell what each image
> is testing for.  I will move them into a fsck directory tho.

David might have meant "001-bad-file-extent-bytenr.img" though.
 
>>
>>> --- /dev/null
>>> +++ b/tests/fsck-tests.sh
>>> @@ -0,0 +1,34 @@
>>> +#!/bin/bash
>>> +#
>>> +# loop through all of our bad images and make sure fsck repairs them properly
>>> +#
>>> +# It's GPL, same as everything else in this tree.
>>> +#
>>> +
>>> +TEST_DEV=""
>>
>> I found the current test hard to use, eg. I can't just do 'make test'
>> from the toplevel dir. The script fsck-tests.sh expects TEST_DEV to be
>> set, but there's no way to do that, because it's set unconditionally to
>> empty string.
> 
> Yeah I wasn't sure how I wanted to do this.  At first I thought about making the
> fsck tester just make a loop device, but I didn't want to override something if
> people were already using a loop device.  But maybe I'll just default to using
> loop5 or something big like that and then if the user wants to change it they
> can go into the script and change it themselves.  How does that sound?  Thanks,

Dumb question, can you just point btrfsck at the image itself w/o setting up
loopback?  i.e. do something like: 

# btrfs-image -r 001-bad-file-extent-bytenr.img test.img
# btrfsck --repair test.img

-Eric

> Josef
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2013-09-09 19:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-06 18:50 [PATCH] Btrfs-progs: add make test framework Josef Bacik
2013-09-09 16:32 ` David Sterba
2013-09-09 17:13   ` Josef Bacik
2013-09-09 19:07     ` Eric Sandeen [this message]
2013-09-09 19:57       ` Josef Bacik
2013-09-09 23:31         ` David Sterba

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=522E1C7F.1010905@redhat.com \
    --to=sandeen@redhat.com \
    --cc=dsterba@suse.cz \
    --cc=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.