Re: HAMMER update 23-Feb-2008

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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
:filesystem)
:# 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.
:
:Cheers.

    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>