BAD FREE LIST in Microport SV/AT 2.3U

[Seth J. Bradley]

In article <514 at wm6r.UUCP> jjt at 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