From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:26314 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750804AbaLODyb convert rfc822-to-8bit (ORCPT ); Sun, 14 Dec 2014 22:54:31 -0500 Message-ID: <548E5B77.7050000@cn.fujitsu.com> Date: Mon, 15 Dec 2014 11:54:31 +0800 From: Qu Wenruo MIME-Version: 1.0 To: , Filipe David Manana , "linux-btrfs@vger.kernel.org" Subject: Re: [PATCH v4 00/13] btrfs-progs:fsck: Add inode nlink mismatch and References: <1418113652-25088-1-git-send-email-quwenruo@cn.fujitsu.com> <20141210123750.GA27601@twin.jikos.cz> <5488EA3D.9080905@cn.fujitsu.com> <548A378F.6020101@cn.fujitsu.com> <20141212153147.GR27601@twin.jikos.cz> <548E38A6.4030301@cn.fujitsu.com> In-Reply-To: <548E38A6.4030301@cn.fujitsu.com> Content-Type: text/plain; charset="utf-8"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: -------- Original Message -------- Subject: Re: [PATCH v4 00/13] btrfs-progs:fsck: Add inode nlink mismatch and From: Qu Wenruo To: dsterba@suse.cz, Filipe David Manana , 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 > To: Filipe David Manana > 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. >