Re: [PATCH v4 00/13] btrfs-progs:fsck: Add inode nlink mismatch and

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message --------
Subject: Re: [PATCH v4 00/13] btrfs-progs:fsck: Add inode nlink mismatch and
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: dsterba@suse.cz, Filipe David Manana <fdmanana@gmail.com>, 
linux-btrfs@vger.kernel.org <linux-btrfs@vger.kernel.org>
Date: 2014年12月15日 09:25
> The binary image dump is definitely working, but the size still seems 
> not so good.... :-(
>
> For my case, 64M contains my /etc copy even after xz with -9 option, 
> the size is still about 2.8M. (although
> xz is already doing great job).
> I know there is even larger btrfs-image dump case here, but several 
> megabytes size binary still seems
> not so good for me.
>
> But on the other hand, btrfs-image with -c9 dump the uncorrupted fs 
> image to less than 200K.
> The point is that, I know exactly which leaf I can corrupt to produce 
> the corrupted image and in fact,
> I am using my leaf corruption patch to do 
> it(https://patchwork.kernel.org/patch/5170691/), even
> without the patch, I can still figure out where the leaf is and can 
> use dd to corrupt the leaf.
>
> So why not change the test cases to following method?
> 1. Untar the tar.gz, which contains the corruption script + a 
> btrfs-image dump.
> 2. Exec the corruption script to corrupt the image (Of course, 
> btrfs-corrupte-image must be able to corrupt it)
> 3. Do the test.
>
> The trick may be step 2., which means every new repair function should 
> have a corresponding corrupt function.
>
> The above is just a advice, I will still submit the binary image dump 
> for now.
>
> Thanks,
> Qu
>
Oh, I'm terribly wrong about the
the 2M+ size binary xz image is a disaster for submitting a patch, 
base64(?) encoded patch grows to
3.6M, I'd better use the btrfs-image dump + custom corrupting script method.

Thanks,
Qu
> -------- Original Message --------
> Subject: Re: [PATCH v4 00/13] btrfs-progs:fsck: Add inode nlink 
> mismatch and
> From: David Sterba <dsterba@suse.cz>
> To: Filipe David Manana <fdmanana@gmail.com>
> Date: 2014年12月12日 23:31
>> On Fri, Dec 12, 2014 at 08:34:09AM +0000, Filipe David Manana wrote:
>>> Very simple solution.
>>>
>>> Do:
>>>
>>> 1) Create an empty file;
>>> 2) Use it as the backing file for a loop device;
>>> 3) Run mkfs.btrfs against the loop device;
>>> 4) Mount it;
>>> 5) Populate the fs;
>>> 6) Umount it;
>>> 7) Corrupt some nodes or leafs (by zeroing them out for e.g.);
>>> 8) Create a tarball from the backing file like this: ZX_OPT=-9 tar
>>> cJSvf foobar.tar.xz run.sh backing_file
>>> 9) Add the tarball to the fsck-tests directory;
>>> 10) Make the test run fsck against the backing file extracted from the
>>> tarball - fsck can operate against regular files, and not only against
>>> devices.
>> I made a few scripts that help to automate most of the steps (no
>> populating or fuzzing), attached.
>