Date: Fri, 09 Jun 2006 01:25:35 -0600 From: Scott Long <scottl@samsco.org> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: fs@freebsd.org, mckusick@freebsd.org Subject: Re: heavy NFS writes lead to corrup summary in superblock Message-ID: <4489226F.8070704@samsco.org> In-Reply-To: <200606081346.04908.mi%2Bmx@aldan.algebra.com> References: <200606081346.04908.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4489226F.8070704>