Date: Sun, 26 Jan 1997 01:07:52 +1100 From: Giles Lean <giles@nemeton.com.au> To: Joshua Pincus <pinc_cif@uhura.cc.rochester.edu> Cc: freebsd-scsi@freebsd.org Subject: Re: DISASTER! Message-ID: <199701251407.BAA06874@nemeton.com.au> In-Reply-To: <199701250946.EAA18319@uhura.cc.rochester.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Jan 1997 04:46:25 -0500 (EST) Joshua Pincus wrote: > ** /dev/rsd0s1e > BAD SUPER BLOCK: NCYL LESS THAN NCG*CPG > pid 161 (fsck), Uid 0: exited on signal 8 > floating exception - core dumped (First note: none of this is SCSI specific.) The following suggestions are pretty much in order of desirability. Try running fsck with an alternate superblock. If you don't know the number of an alternate superblock, try 32. To find superblocks you can read the partition looking for blocks that have FS_MAGIC in the right place -- I've included some code for this below. (Whether this code compiles untweaked on FreeBSD right now I don't know, but it has saved me a couple of partitions that I decided I wanted *after* I trashed the disklabel.) Dig into fsck and fix the (probable) divide by zero. There was a PR or mail item recently about a fsck core dump; might be the same one. > Second of all, is there any way I can retrieve the information off of > this partition? Our backup system is on the blink, and it is imperative > that the information in this partition be extracted. Ouch. Yes, you should still be able to read some of the data. I suspect you'll need to get a sorta-kinda-valid superblock before you can do much. Corrupted filesystems can be mounted (sometimes) and if all your filesystems are mounted read only no more harm will occur even if the machine panics. If you can't get a mountable filesystem but have some sort of superblock Tom Christiansen's "icat" program which retrieves files by inode number might be useful. (Don't know if I've compiled this on FreeBSD, either, but I've included it below as well.) The filesystem might be totally toast, of course. :-( > Can I relabel the disk in order to validate the superblock No. Someone familiar with filesystem hacking should be able to get some of the data off even if the above tools fail, or even write a program (or use a debugger -- I don't know gdb well) to manually reconstruct the superblock. Failing that, if you just need a particular file or two 'strings' on the filesystem (onto a *big* scratch file) might be enough. I've pulled data out of a trashed database in this way. (This was nasty -- I had no data on the internal data structures, so couldn't do anything much smarter.) Good luck! Don't do anything rash without seeking further opinions -- some of the data recovery services could doubtless help, at a price. Giles #text/plain; name=findsb.c src/findsb.c #text/plain; name=icat.c src/icat/icat.c #text/plain; name=icat.man src/icat/icat.man
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701251407.BAA06874>