:You are right that the buffer cache is very tricky. It is hard to
:change it in ways that preserves functionality and performance.
:The port of my buffer locking code from BSD/OS has caused problems
:largely because of a different buffer cache implementation and
:especially SMP models between the two systems (BSD/OS has no spl's
:for example). However, this is not a half baked idea that I have
:come up with and thrown in without thinking.  Recursive locking is
:*required* to get stacking filesystems like union and loopback
:working reliably. As they currently stand they are full of code to
:try and track locks at layers all up and down the stack. This code
:is really nasty and in many cases broken (leading to deadlocks or
:crashes). The snapshot code also is most easily implemented with
:recursive locking, the alternative being to put lock monitoring
:all through bmap and block allocation code. So yes, it would be
:wonderful if the world could be simple, and I am not a huge fan of
:the complexity of the buffer locking code. But, I have considered
:the alternatives and they are worse.
:
:       Kirk

    Wow!  Timeout!  Miscommunication.

    I am talking strictly about struct buf locking.  I understand and agree
    completely that recursive locking is absolutely necessary for the 
    VFS layering!

    I am not throwing your work out - precisely the opposite, I want to keep
    your work pretty much as is except for two things: (1) I want to replace
    lockmgr locks ( and I don't mind implementing recursive exclusive locking
    in the replacement, though I would rather avoid it! ), and (2) I want to
    find a better way to implement the BUF_KERNPROC() stuff... basically I
    want to try to find a way to localize the necessary effect in one place
    in the code rather then have the BUF_KERNPROC() macros strewn all over the
    code.  Same effect, slightly different code organization, that's all.

    There must be a choke point somewhere where we can put the code.

                                        -Matt
                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to