BAD FREE LIST in Microport SV/AT 2.3U

Jay "you ignorant splut!" Maynard jay at splut.conmicro.com
Sun Nov 26 10:29:44 AEST 1989


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:
>  ** Phase 5 - Check Free List 
>  -3022 BLK(S) MISSING
>  BAD FREE LIST
>  SALVAGE? y <== this is a fatal mistake.

>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?

Time to trot this one out again, I guess...

This is a well-known bug. Your /dev/dsk/1s1 filesystem is large enough to
require a work file (either via -t or by prompt). The free list info is
built during phase 1, and is clobbered somewhere during phases 2-4.
Phase 5 uses the now corrupted data to check the free list, and phase 6
uses it (still corrupted) to rebuild the free list.

The workaround is to fsck any filesystem large enough to require a
working file twice. The first time, reply yes to any prompt until you
are told that the free list is corrupt; at that time, reply no to the
"SALVAGE?" query. If you get an "excessive duplicate blocks" prompt, you
must reply yes to the "CONTINUE?" question in order to get the
"SALVAGE?" question; if you do not allow it to continue, the last
changed buffer will not be rewritten. After fsck terminates when you've
told it not to salvage the free list, then rerun fsck specifying -f;
this will rebuild the free list properly.
Note that this procedure is only necessary if a workfile is needed. fsck
will work properly if all info can be contained in memory.

Hope this helps...

-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
jay at splut.conmicro.com       (eieio)| adequately be explained by stupidity.
{attctc,bellcore}!texbell!splut!jay +----------------------------------------
 "...when hasn't gibberish been legal C?" -- Tom Horsley, tom at ssd.harris.com



More information about the Comp.unix.microport mailing list