Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!vsi1!zorch!dalek!sjb From: sjb@dalek.UUCP (Seth J. Bradley) Newsgroups: comp.unix.microport Subject: Re: BAD FREE LIST in Microport SV/AT 2.3U Message-ID: <30@dalek.UUCP> Date: 25 Nov 89 23:32:16 GMT References: <514@wm6r.UUCP> Reply-To: sjb@dalek.UUCP (Seth J. Bradley) Organization: Bradley Marketing, San Jose, CA Lines: 62 In article <514@wm6r.UUCP> jjt@wm6r.UUCP (John Thornton) writes: >The file system used here for /usr/spool/news has become corrupted about >every 6 months, an fsck gives: > > /dev/dsk/1s1 > File System: Volume: > > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Free List > -3022 BLK(S) MISSING > BAD FREE LIST > SALVAGE? y > > ** Phase 6 - Salvage Free List > 5423 files 33234 blocks 13358 free > *** FILE SYSTEM WAS MODIFIED *** > >Unfortunately, fsck isn't able to fix the file system and I end up >remaking the file system and restoring from backups. I am at a loss as to >why fsck shows a large negative number of blocks missing. The file system >is unmounted during this operation. Successive fscks give the same message. > >Anyone know of a work around for this? The text below is taken from a list of microport bugs posted over two years ago. To my knowledge, the fsck bug was never fixed, but there is a work around. 605 Priority: 1 Release: 2.2 Found in: fsck Verified fsck can give negative numbers and trash file system when you have a very large file system Work Around: use fsck -f to repair, and then check with fsck I got asked about the fsck bug I mentioned before. Here's the analysis that Steve Nuchia (uunet!nuchat!steve) gave me as to the problem: If fsck needs to use a work file, it gets confused. During phase 1, it builds a map of all the used sectors in memory, using the work file as a virtual memory extension. During phase 2, it clobbers that file. During phase 5, it uses the (now clobbered) file to check the free list, and, if it finds a discrepancy (which it is likely to do), then it uses the (still clobbered) file during phase 6 to rebuild the free list. I don't know what parameters fsck uses to determine that he needs a work file, but it's easy enough to determine if your file system is big enough to require one: fsck it with 'fsck -n /dev/dsk/0s2' (or whichever). If it asks you for a file name, then it's big enough. In that case, I recommend that you d o the following to avoid having the bug trash your file system: 1) Edit /etc/bcheckrc and /etc/mountall and remove the -y flags from the fsck commands. This will make fsck ask before it does anything to your file system. 2) If you get fsck invoked, answer 'no' to the question "BAD FREE LIST. SALVAGE?". This will cause your file system to still be bad, but does not use the clobbered map information to rebuild (==clobber) your free list. 3) Rerun fsck manually, as 'fsck -f /dev/dsk/0s2' (or whatever). This only invokes passes 1 and 5, and 6 if needed, avoiding the corruption from pass 2. Allow it to set the 'file system OK' flag. This procedure will rebuild the file system, and do so cleanly. -- Seth J. Bradley UUCP: uunet!{lll-winken|zorch}!dalek!sjb Internet: lll-winken.llnl.gov!dalek!sjb