fixing a corrupt /dev/hdar .. debugfs assistance...

[Chris Worley]

Note that I was able to mount the file system, and as Ted said, all
the directories were under a directory in lost+found.

Can I assume that if a file exists in the subdirectories that it's
okay?  Or, in other words, what's the best way to assure the the files
found are good?

Thanks,

Chris
On 3/28/06, Chris Worley <worleys at gmail.com> wrote:
> 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
> >
>