[NCLUG] Hard disk failure

dobbster dobbster at dobbster.com
Sun May 20 22:25:33 MDT 2001


> >From the mke2fs man page:
> 
>        -S     Write  superblock and group descriptors only.  This
>               is useful if  all  of  the  superblock  and  backup
>               superblocks  are corrupted, and a last-ditch recov­
>               ery method is desired.  It causes mke2fs to  reini­
>               tialize the superblock and group descriptors, while
>               not touching the inode  table  and  the  block  and
>               inode  bitmaps.   The  e2fsck program should be run
>               immediately after this option is used, and there is
>               no guarantee that any data will be salvageable.
> 
> Short version:  You can try and rebuild your superblock and group descriptors
> table using this flag, and not touch the inodes/inode tables.  Note that this
> IS a method of last resort, and you DO run the risk of fux0ring the data
> completely...  However, if nothing else works, it's worth a shot.

Ok...  You mentioned -n (-N?) before, but when looking at the man page, I
couldn't find anything similar.  -S clearly isn't quite the same, but at least
it (hopefully) leaves the data there...
 
> >  I get the same results using other superblocks besides 32768.  Shouldn't
> > there
> >  be superblocks prior to that?
> 
> Depends on the flags that your filesystem was created with -- with a default
> installation of a recent version of Debian (unstable, in fact!) that is not
> the case -- it builds with 4096 bytes per inode, and 8192 inodes per inode
> group.  Unless you know some more statistics about the filesystem and/or have
> the flags that the filesystem was initially created with, I can't tell you.
> However, if you're running recent RH or derivatives (KRUD, SuSE, Mandrake,
> etc) or most any other modern distro, you most likely had no choice in how
> the filesystems were created, so I can only guess.

This is a Mandrake 7.1 system.  I'm not sure what the bytes/inode is.
 
> >  It seems weird that installing some Windows software could cause all of
> > this
> >  damage.  I don't even know what an "illegal triply indirect block" is.
> 
> Make the next NCLUG meeting.  If we're available with lecture space there,
> I'll do a presentation on how filesystems work.  Otherwise, I'll post again
> shortly on it.  I learned this stuff in my Sun class last week, actually --
> interesting material.

Alas, now I am committed to leave my dungeon and be semi-sociable at an NCLUG
meeting. :-)  I'll plan on attending (6/5, I assume.)
  
> Another thing that just hit my mind:  did your operating kernel rev change to
> a pre-2.2 kernel?  There are some modes of the ext2 filesystem that won't
> work with those older kernels...  And I just realized it.  If you're running
> an ancient ass kernel for some reason, that might explain it.  Hmm.  Check
> your bootup messages and let us know.

It's 2.2.15.
 
> Is there some time next weekend that we could meet somewhere (my place/office
> or yours) and I could take a gander at the system?   This actually poses an
> interesting problem, and I'd love to see it through.

Sure; if you like, I can leave the machine alone until then.  There's no big
rush.  Scheduling a time might be challenging for me.  Can we maybe get in
contact sometime later in the week?

Thanks again...

Mark (dobbster at dobbster.com)



More information about the NCLUG mailing list