From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Daniel Taylor <Daniel.Taylor@wdc.com>, linux-ext4@vger.kernel.org
Subject: Re: breaking ext4 to test recovery
Date: Tue, 29 Mar 2011 16:33:05 +0200 [thread overview]
Message-ID: <20110329143305.GA6057@bitwizard.nl> (raw)
In-Reply-To: <4D91E39A.3000800@redhat.com>
On Tue, Mar 29, 2011 at 08:50:18AM -0500, Eric Sandeen wrote:
> Another tool which can be useful for this sort of thing is
> fsfuzzer. It writes garbage; using dd to write zeros actually
> might be "nice" corruption.
Besides writing blocks of "random data", you could write blocks with a
small percentage of bits (byte) set to non-zero, or just toggle a
configurable number of bits (bytes). This is slightly more devious than just
"random data".
If you try to verify the integrity of a block full of random data, you
can quickly determine that it is completely bogus (I don't think that
e2fsck already exploits this as I've seen it get this wrong).
If you have an indirect block, and it contains:
00000 72 6f 6f 74 3a 78 3a 30 3a 30 3a 72 6f 6f 74 3a root:x:0:0:root:
00010 2f 72 6f 6f 74 3a 2f 62 69 6e 2f 62 61 73 68 0a /root:/bin/bash.
00020 64 61 65 6d 6f 6e 3a 78 3a 31 3a 31 3a 64 61 65 daemon:x:1:1:dae
00030 6d 6f 6e 3a 2f 75 73 72 2f 73 62 69 6e 3a 2f 62 mon:/usr/sbin:/b
00040 69 6e 2f 73 68 0a 62 69 6e 3a 78 3a 32 3a 32 3a in/sh.bin:x:2:2:
00050 62 69 6e 3a 2f 62 69 6e 3a 2f 62 69 6e 2f 73 68 bin:/bin:/bin/sh
00060 0a 73 79 73 3a 78 3a 33 3a 33 3a 73 79 73 3a 2f .sys:x:3:3:sys:/
00070 64 65 76 3a 2f 62 69 6e 2f 73 68 0a 73 79 6e 63 dev:/bin/sh.sync
00080 3a 78 3a 34 3a 36 35 35 33 34 3a 73 79 6e 63 3a :x:4:65534:sync:
00090 2f 62 69 6e 3a 2f 62 69 6e 2f 73 79 6e 63 0a 67 /bin:/bin/sync.g
You can see that the block numbers that are represented here are all
bad. In this case, one of the options should be to discard the whole
indirect block. If you happen to find a few "valid" block numbers
here, they are likely to be bogus. It is counterproductive to check
those for duplicate allocation, or to mark them as used if they happen
to be free.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
next prev parent reply other threads:[~2011-03-29 14:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 2:45 breaking ext4 to test recovery Daniel Taylor
2011-03-29 3:10 ` Tao Ma
2011-03-29 13:50 ` Eric Sandeen
2011-03-29 14:33 ` Rogier Wolff [this message]
2011-03-29 17:33 ` Greg Freemyer
2011-03-29 22:26 ` Daniel Taylor
2011-03-29 22:33 ` Eric Sandeen
2011-03-31 22:11 ` Andreas Dilger
2011-03-31 22:22 ` Andreas Dilger
2011-03-31 22:21 ` Andreas Dilger
2011-03-31 22:44 ` Eric Sandeen
2011-04-01 15:26 ` Lukas Czerner
2011-04-01 15:52 ` Ric Wheeler
2011-04-02 2:15 ` Andreas Dilger
2011-04-02 12:38 ` Ric Wheeler
2011-04-02 18:50 ` Andreas Dilger
2011-04-03 2:37 ` Tao Ma
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=20110329143305.GA6057@bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=Daniel.Taylor@wdc.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).