heavy NFS writes lead to corrup summary in superblock

[Scott Long]

Mikhail Teterin wrote:

> Our amd64 6.1-STABLE system is used to collect backup dumps from production 
> systems (mostly -- Solaris) via NFS. When in progrss, the dumps arrive at an 
> average rate of 20Mb/s.
> 
> Every once in a while I notice a discrepancy in the amount of used space on 
> the backup FS as reported by df vs. that reported by the total du.
> 
> Unmounting the FS and fsck-ing it fixes the problem with fsck reporting 
> (despite the clean unmount):
> 
> 	SUMMARY BLK COUNT(S) WRONG IN SUPERBLK
> 	SALVAGE? yes
> 
> The FS is intended for very few very large files and was created 
> with "newfs -b 65536 -O1" (no softupdates).
> 
> This workaround (explicit fsck) is acceptable for us, but it is a sign of some 
> kind of rot, and I thought, you'd like to know...
> 
> Yours,
> 
> 	-mi

Due to delayed writes in NFS, I guess that it would be very possible for
df and du to disagree at times; a file might  get grown due to a setattr
call over the wire (which would be reflected in du), but not actually 
grow to consume more disk blocks until the delayed writes get committed.
In any case, it's very worrying that an unmount would not flush all of
this and return the filesystem to consistency.

Scott