Date: Fri, 09 Jun 2006 10:58:52 -0600 From: Scott Long <scottl@samsco.org> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: fs@freebsd.org Subject: Re: heavy NFS writes lead to corrup summary in superblock Message-ID: <4489A8CC.8030307@samsco.org> In-Reply-To: <200606091253.37446.mi%2Bmx@aldan.algebra.com> References: <20060609065656.31225.qmail@web30313.mail.mud.yahoo.com> <200606091253.37446.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote: > п'ятниця 09 червень 2006 02:56, R. B. Riddick написав: > >>I say, does that discrepancy persist, when you just wait some time? > > > Yes... I'm noticing this hours after the dumps ended... > > >>I would guess, that something has an open file descriptor on a deleted >>file, so that this file cannot be really deleted (it just disappears from >>the directory tree)... > > > If anything did, I wouldn't be able to umount the filesystem cleanly, would I? > Yet, it unmounts peacefully, even though the subsequent fsck finds the > superblock summary to be incorrect. > > When I tried to use the FS as a scratch for an unrelated thing, though, I > noticed some processes hanging in nbufkv state. Google-ing led me to the: > > http://lists.freebsd.org/pipermail/freebsd-current/2003-June/004702.html > > Is this 3 year old advise *still* true? I rebuilt the kernel with BKVASIZE > bumped to 64K (the block size on the FS in question) and am running another > batch of dumps right now. When it is over, I'll check the df/du... > > Yours, > > -mi Can you actually measure a performance difference with using the -b 65535 option on newfs? All of the I/O is buffered anyways and contiguous data is already going to be written in 64k blocks. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4489A8CC.8030307>