fsck -x fabricating inconsistencies?

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

[I know fsck is a userland program, but it's heavily tied to the kernel and 
the problem may be with snapshots, not fsck.]

After an unidentified (black sreen, completely unresponsive) crash of our file 
server (losing 2300 days of uptime), which came back up with no apparent 
issues, I decided to play safe (or so I thought) and run fsck -f -n -x /var/db 
on the NFS-exported (FFSv2, WAPBL, quota2) file systems.

The smaller ones showed no issues, but the two larger ones seemed to exhibit 
serious inconsistencies (unallocated/partly allocated inode, directory contains 
empty blocks, pass5: bad magic number, quota id in wrong hash list, link count 
0 should be -1, etc.) (add CAPS LOCK for the real fsck messages, of course); 
around 10k to 15k problems per fs.

I mentally prepared to newfs and restore from a backup, but running a "real" 
fsck (in single user mode, after unmounting) showed ZERO issues (on one fs, 
two trial ones on the other).

The only sightly unusual thing about those file systems is using quota2 and 
being null mounted elsewhere (/emul/linux32 for running TSM), but these 
properties are shared between the "good" and "bad" ones.

This looks like a bug in fss, but we also use snapshots for backups (the null 
mounts described above are just a safety net against snapshotting failure 
ruining the backup) on a daily basis for years.

I have to admit that's on NetBSD-6, but I'm not aware of any fixes in the 
fss area.