Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watcgl.UUCP
Path: utzoo!watmath!watcgl!dmmartindale
From: dmmartindale@watcgl.UUCP (Dave Martindale)
Newsgroups: net.bugs.4bsd
Subject: BAD FREEBLK COUNT in fsck
Message-ID: <892@watcgl.UUCP>
Date: Thu, 29-Sep-83 11:31:20 EDT
Article-I.D.: watcgl.892
Posted: Thu Sep 29 11:31:20 1983
Date-Received: Fri, 30-Sep-83 01:25:01 EDT
Organization: U of Waterloo, Ontario
Lines: 23

Every once in a while, fsck fails after a crash because of a BAD FREEBLK
COUNT problem; it knows how to fix the free list, but thinks that this
shouldn't happen simply because of a crash.  Now, I see nothing preventing
the following from happening:  In the course of allocating a free block,
the system has to read in the next block of free block pointers; it then
immediately re-uses that block for data.  Before the superblock gets
written out, the system crashes.  Thus the superblock on disk thinks
that this block (which now contains data) is still a free block, and
probably has a bad free block count.  (It's also possible for the first
longword of data looks like a good count, and the rest of the block to be
taken as free block pointers.)  The only way to prevent this is to queue
the superblock for writing and wait for it to complete every time
a new block of free list pointers is read in.  Since this might slow down
allocation quite a bit, I didn't do it; it's easy enough for fsck to
clean up any mess that happens to be left.  All that is necessary is
to have it think that this is a normal, preenable error:

1611,1612c1614
< 			pfatal("BAD FREEBLK COUNT");
< 			printf("\n");
---
> 			pwarn("BAD FREEBLK COUNT\n");