From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f174.google.com ([209.85.223.174]:49544 "EHLO mail-ie0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758034Ab2IEB7z (ORCPT ); Tue, 4 Sep 2012 21:59:55 -0400 Received: by ieje11 with SMTP id e11so6626538iej.19 for ; Tue, 04 Sep 2012 18:59:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5046452C.7090804@libero.it> References: <5046452C.7090804@libero.it> From: Shentino Date: Tue, 4 Sep 2012 18:59:13 -0700 Message-ID: Subject: Re: rfc: fuzz testing by direct writes to device To: kreijack@inwind.it Cc: Michael , cwillu , linux-btrfs@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Tue, Sep 4, 2012 at 11:15 AM, Goffredo Baroncelli wrote: > Hi, > > > On 09/02/2012 03:03 AM, Shentino wrote: >> >> This whole subject was also about using sed to corrupt-o-magic a >> file's data on disk. >> >> Is this an acceptable method for testing? > > I am not sure that doing "sed /dev/sdX ..." is the right thing to > do, because it rewrites the full disk. This means that: > - it takes a lot of time > - you don't have any control about which part of the disk you change: what > happens if sed write a block which is update in parallel by BTRFS ? Which is one reason I used a sha1 hash of a random read as the search key :P > Anyway I suggest to give a look to the following video [1], which explains > the automatic repair. Moreover it shows [2] how corrupt a block with the > "btrfs-corrupt-block" command. That does sound more convenient. > Hoping that this helps you. > > BR > G.Baroncelli > > [1] http://www.youtube.com/watch?v=hxWuaozpe2I > [2] See minute 17:52 of the video above > >> >> On Sat, Sep 1, 2012 at 4:49 PM, Michael wrote: >>> >>> It should not. It is always preferred that you dd your drive onto >>> another disk just in case though. >>> >>> On Sat, Sep 1, 2012 at 5:31 PM, Shentino wrote: >>>> >>>> On Sat, Sep 1, 2012 at 1:59 PM, cwillu wrote: >>>>> >>>>> You still haven't said which kernel you were running; the thing to do >>>>> is try the very latest rc (if not btrfs-next). >>>> >>>> >>>> Sorry about that! >>>> >>>> I thought I included it. >>>> >>>> 3.3.8 >>>> >>>> Hmm...seems it's been EOL'ed. I need to yell at my distro. >>>> >>>> In the meantime, will mounting a btrfs filesystem with a new kernel >>>> render it unmountable by older kernels? >> >> -- >> >> 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 >> . >> >