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@xxxxxxxxx> 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
> >
>
_______________________________________________
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
