Hi Everyone,
I've solved my problem, and here is the problem & solution for the
archives.
Problem
=======
I had a disk crash. Of course backups were out of the question (but I have
learnt my lesson this time for sure :-). fsck fixed 2 out of 3 partitions
with a few files in lost+found. I mounted those partitions ro and copied
off files.
The last partition (/var or /dev/wd1s1e) had problems...running fsck:
--example--
# fsck /dev/wd1s1e
** /dev/rwd1s1e
CANNOT READ: BLK 16
CONTINUE? [yn] y
THE FOLLOWING DISK SECTORS COULD NOT BE READ: 31,
LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y
USING ALTERNATE SUPERBLOCK AT 32
** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
CLEAN FLAG NOT SET IN SUPERBLOCK
FIX? [yn] y
709 files, 7807 used, 12008 free (904 frags, 1388 blocks, 4.6%
fragmentation)
UPDATE STANDARD SUPERBLOCK? [yn] y
CANNOT WRITE: BLK 16
CONTINUE? [yn] y
THE FOLLOWING SECTORS COULD NOT BE WRITTEN: 31,
***** FILE SYSTEM WAS MODIFIED *****
--eoe--
it seems my superblock was damaged. My backup copy was Ok as fsck could
use it. fsck tried to restore the master superblock from the backup but
got a disk error (this disk is sick).
I couldnt mount /var as mount died with an I/O error...presumably trying
to read the super block.
I used fsdb to look at the disk and all/most of the data was still there.
I could get the inode numbers of the files I wanted but had no idea how to
get the data, even though I felt sure it was possible.
SOLUTION
========
1) use dd to make the partition a file:
dd conv=noerror,sync if=/dev/wd1s1e of=var.file
2) use ffsrecov (from ports) to scan that file for backup superblocks (my
primary super block was corrupt so ffsrecov would crash if I tried to
recover anything)
ffsrecov -s var.file
You will get something like:
superblock: 16384(byte), 32(block)
superblock: 1312912(byte), 2564(block)
remeber the byte address of one of the superblocks.
3) edit main.c (from ffsrecov) and find the line:
pi.fs = pi.map + SBOFF;
replace SBOFF with whatever address you found in part 2 so the line now
reads:
pi.fs = pi.map + 16384;
4) recompile ffsrecov
cd ffsrecov
make
5) recover as per normal
ffsrecov -c 2 -n var var.file
NOTE: If you dont know the inode your after:
a) indoe 2 is always the root of the filesystem so if your lucky
specifiying this gets you everything
b) you can use fsdb to find the inode. Its the number in the ino
column.
--example--
# fsdb /dev/rwd1s1e
** /dev/rwd1s1e
CANNOT READ: BLK 16
CONTINUE? [yn] y
THE FOLLOWING DISK SECTORS COULD NOT BE READ: 31,
LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y
USING ALTERNATE SUPERBLOCK AT 32
Editing file system `/dev/rwd1s1e'
Last Mounted on
current inode: directory
I=2 MODE=40755 SIZE=512
MTIME=Jul 4 08:14:18 1999 [0 nsec]
CTIME=Jul 4 08:14:18 1999 [0 nsec]
ATIME=Mar 18 03:36:26 2000 [0 nsec]
OWNER=root GRP=wheel LINKCNT=18 FLAGS=0 BLKCNT=2 GEN=5022f135
fsdb (inum: 2)> ls
slot 0 ino 2 reclen 12: directory, `.'
slot 1 ino 2 reclen 12: directory, `..'
slot 2 ino 3 reclen 16: directory, `account'
slot 3 ino 4 reclen 12: directory, `at'
slot 4 ino 7 reclen 16: directory, `backups'
slot 5 ino 8 reclen 16: directory, `crash'
slot 6 ino 10 reclen 16: directory, `cron'
<snip>
--eoe--
Thanks to everyone for the great tools, especially John-Mark Gurney for
ffsrecov (and for his help last time I had a disk die).
I have a few questions though (perhaps showing my lack of knowledge)...
1) why isnt there an option to mount (like -b to fsck) to tell it to look
at a different copy of the superblock? This may imply -o ro. Corrupt
file systems may panic the machine but that may be the lesser of 2 evils.
2) why dosn't ffsrecov have an option to use the discovered superblocks
rather than having to patch the code? I'm guessing someone will say its
because I haven't sent in the patches yet :-)
3) why dosn't fsdb have the ability to save the data of an inode to a
different fs? This was mentioned as a possible new feature a few years ago
according to the archives. Was it decided that this was a bad idea or did
it just never get done?
4) why didn't I buy a tpe drive last time I had a disk fail...
Thankyou again,
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
