-------- Original Message --------
Subject: Re: [PATCH v4 00/13] btrfs-progs:fsck: Add inode nlink mismatch and
From: Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>
To: dsterba@xxxxxxx, Filipe David Manana <fdmanana@xxxxxxxxx>,
linux-btrfs@xxxxxxxxxxxxxxx <linux-btrfs@xxxxxxxxxxxxxxx>
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@xxxxxxx>
To: Filipe David Manana <fdmanana@xxxxxxxxx>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
