Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!speck@cit-vlsi.arpa
From: speck@cit-vlsi.arpa (Don Speck)
Newsgroups: net.unix-wizards
Subject: Re: fsck problem
Message-ID: <1732@brl-tgr.ARPA>
Date: Sat, 18-Jan-86 21:02:38 EST
Article-I.D.: brl-tgr.1732
Posted: Sat Jan 18 21:02:38 1986
Date-Received: Mon, 20-Jan-86 06:35:21 EST
Sender: news@brl-tgr.ARPA
Lines: 42


    Patching 4.2 filesystems needn't be as frightening as Barry
describes.  I've had a number of occasions to do it on our Suns,
when a block of inodes shifts by a word or two, and fsck and dump
are obviously hopeless.  So you use adb -w.

    If the filesystem is so addled that fsck can't handle it,
there's only one reasonable way to backup before you patch:  dd.
Restore will reject a dump of an addled filesystem.  Once when
trying to move a filesystem between VAXen, restore kept dumping
core; it finally dawned on me to fsck the filesystem, and of course it
flunked.  It had a corrupted directory, which fsck asked permission
to salvage, but didn't manage to do.  Sound familiar?

    I mounted the filesystem read-only, and ls said the directory
was about 80K too big.	It had gotten some trash appended to it.

(I don't consider this a dangerous step; you ALWAYS type 'sync'
before anything dangerous like that, and panic() does one too,
so what's to worry?  If I'm doing something REALLY dangerous,
like touching the SI disk controller, I'll boot with all disks
write-protected.  4.2 will run for a surprisingly long time even
though it's completely unable to page.	Of course I bring it back
down before write-enabling any disks, to avoid stale sync's).

    Fixing the inode was simply a matter of adjusting the length
and zero'ing some daddr's with 'adb -w' on the block device.
Adb makes this relatively easy, with $<dino to print an inode
given its address, and $<dirblk to list a directory block.  Once
you fix the bad parts, fsck can do the rest.  Sure beats restoring
dump tapes on slow tape drives; seems safer, too.

    The hard part is finding the disk address of the inode, given
its inum.  (There oughta be an adb macro...).  All the info you
need can be gotten from the super block, using 'dumpfs'.  Divide
the inum by fs_ipg to get the cylinder group number (cgnum); the
remainder is the inode number within that cylinder group (i).
Then the disk address (in bytes) is:

    ((fs_fpg+fs_cgoffset)*cgnum + fs_iblkno) * fs_fsize + 128*i

Don Speck   speck@cit-{vax,vlsi}.arpa