Thanks for the clarification, I obviously didn't read the man page as
thoroughly as I should have.
I was able to zero-out the 2nd inode (but, I could not dump it to a
file... the resulting file was 0 bytes), and e2fsck got beyond that
point, but is no segfaulting in the 4th pass.
The disk I'm DD'ing to is firewire/USB, so I can move it to different
systems pretty easily. The USB/Firewire disk has more blocks than the
MD1 device I'm trying to resurrect: I couldn't create a partition of
the exact same size, so I just use the whole device (so there will be
trailing garbage at the end of the device/partition that's not part of
the file system).
On one system, fsck segfaults after the 4th pass, on another system,
it nicely reports the segfault and exits:
Warning... fsck.ext2 for device /dev/sdc exited with signal 11.
fsck.ext2 /dev/sdc failed (status 0x8). Run manually!
The last message before the segfault, on either the faulty md1 or the
backup system is:
i_fsize for inode 7663554 (...) is 150, should be zero.
Clear<y>? yes
Why always the same errors? Doesn't e2fsck commit the change when you
respond "Y"?
The same event occurs if I use a different superblock.
Note that in using dd or dd_rescue, there are no errors reading from
the bad disk device (md1).
Off topic: It's also strange that my system w/ a 2.6.11 kernel won't
mount or fsck the USB/Firewire drive, even after making a file system
from scratch.
On 3/21/06, Theodore Ts'o wrote:
> On Tue, Mar 21, 2006 at 01:51:20PM -0700, Chris Worley wrote:
> > Thanks for the help.
> >
> > Does <2> refer to a superblock?
>
> No, <2> refers to inode #2. See the debugfs man page:
>
> SPECIFYING FILES
> Many debugfs commands take a filespec as an argument to specify an
> inode (as opposed to a pathname) in the filesystem which is currently
> opened by debugfs. The filespec argument may be specified in two
> forms. The first form is an inode number surrounded by angle brackets,
> e.g., <2>. The second form is a pathname; if the pathname is prefixed
> by a forward slash ('/'), then it is interpreted relative to the root
> of the filesystem which is currently opened by debugfs. If not, the
> pathname is interpreted relative to the current working directory as
> maintained by debugfs. This may be modified by using the debugfs com-
> mand cd.
>
> - Ted
>
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
