:I've recently upgraded a system from 3.2-RELEASE to -CURRENT as of
:30-Sept (just before the signal changes). I now find that when
:I try to do a CVS checkout, the system hangs, with cvs in `nbufkv'.
:
:The CVSROOT is on a filesystem with standard 8K/1K blocks. The
:target FS is 32k/4k. Both FS are running softupdates. This worked
:without problem under 3.2. The kernel config files are basically
:the same (modulo config(8) changes). FWIW, it has 'maxusers 5'
:and no other options over-riding default kernel memory sizes.
:
:I notice that Matt Dillon found his FS stress program also hung in
:nbufkv, but that was with 64k blocks. Other than that, I can't
:find any reference to nbufkv here, in the PR list or in the sys
:commitlogs.
:
:Does anyone have any ideas? Should I just go back to 8K/1K blocks?
:
:Peter
For production you should definitely go back to 8K/1K blocks. If
you want to help track down the sleep/wakeup problem causing the
nbufkv lockup you should leave them at 32K or higher.
I just recently committed a couple of changes that should fix some
of the nbufkv lockups. There are probably still some holes I haven't
plugged.
Essentially what occurs is that the larger block size exercises a portion
of the buffer cache not usually exercised -- the KVM defragmentation
code, and there are instances where processes sleep waiting for buffer
cache KVM (nbufkv) but never get woken up again.
:--
:Peter Jeremy (VK2PJ) [EMAIL PROTECTED]
:Alcatel Australia Limited
:41 Mandible St Phone: +61 2 9690 5019
:ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message