HAMMER update 23-Feb-2008

Matthew Dillon dillon at apollo.backplane.com
Sun Feb 24 10:55:37 PST 2008

:I've been playing with it, and while it works nice when working on a small
:amount of files, it often locks up(ctrl+T or ctrl+C won't work) during
:a task like this (I've made sure that this has no problem writing on a UFS
:# cpdup /usr/pkgsrc/. /mnt/HAMMER/.
:I added a few kprintf()'s around tsleep()'s and wakeup()'s in
:hammer_subs.c, and I found that it is often the case that it locked up,
:tsleep() won't return (because I didn't see the kprintf() message after it)
:after being woken up by hammer_lock_downgrade().  ctrl+alt+esc mostly
:works, but it takes very long time to drop into DDB once it locked up.

    I'll try to reproduce it.  You should be able to examine the state 
    of the downgraded lock... *SHOULD* the tsleep in the other process
    have woken up?  That is, is the lock in a state where the other
    process ought to have been able to acquire it?

    I've seen similar effects in the vkernel.  The buffer cache deadlocks
    trying to allocate a new buffer from inside a locked path and then
    cascades.  Usually a 'ps axl' shows numerous processes stuck in
    'getnewbuf'.  I can work around it by doing a 'sync' once a second.

    I've separated heavy-weight buffers (buffers which need additional
    buffer operations in order to be able to flush them) from light-weight
    buffers (buffers which can be flushed directly to disk) and that helped
    a lot, but there are still some edge cases.

    In anycase, back to the issue you are seeing... if you can get a
    kernel.debug/kernel-core onto leaf I should be able to figure it out.

					Matthew Dillon 
					<dillon at backplane.com>

More information about the Kernel mailing list