Linux Btrfs filesystem development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox