In another thread I happened to find this in fsck_ffs(8):

     The kernel takes care that only a restricted class of innocuous file sys-
     tem inconsistencies can happen unless hardware or software failures
     intervene.  These are limited to the following:

     Unreferenced inodes
     Link counts in inodes too large
     Missing blocks in the free map
     Blocks in the free map also in files
     Counts in the super-block wrong

I noticed that out of the five listed inconsistencies, four of them are
truly innocuous, in that they won't hurt you badly if you operate the
filesystem without fscking it.  But "blocks in the free map also in files"
would hurt,because with further use of the fs you'd wind up with files
sharing blocks. Does the kernel really allow that? Is the problem that nobody
wants to sync-update the bitmap so frequently?

It occurred to me there's an idea that could probably be tweaked to keep the
bitmap updates down: work from a cache of the bitmap, and whenever a region
(of tunable size) of the cache is loaded from disk, sync-write that region
with all bits clear.  In an unclean shutdown, the bitmap'll be wrong, but
only wrong with missing free blocks, which really is innocuous.

Worth considering, or not?

-Chap