heavy NFS writes lead to corrup summary in superblock

Scott Long scottl at samsco.org
Fri Jun 9 16:59:26 UTC 2006


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


More information about the freebsd-fs mailing list