DragonFly BSD
DragonFly kernel List (threaded) for 2006-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: nullfs stabilization I

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 14 Jan 2006 10:11:36 -0800 (PST)

:I still don't understand at which point we want to associate the upper 
:layer with the lower layer.  I think this has to be done upon creation 
:of the upper namecache record, which means in cache_lookup().
:Otherwise cache_lookup() will return a namecache record which is a) 
:locked but b) not sharing the lock with lower layers, because it doesn't 
:have the association yet.  I don't think this will work.  Especially if 
:we want to have one shared locking structure, we need to associate every 
:record with this structure from the beginning (== in cache_lookup()).
:But doing this in cache_lookup() requires a VFS upcall there.  Either by 
:resolving the namecache directly (slow) or by just associating it with a 
:lower layer namecache record (and the glue lock, at the same time), via 
:a vfs_getshadow() upcall, for instance.
:maybe i'm just missing something quite obvious how to get this locking 
:right without needing this upcall in cache_lookup(), but i just don't 
:see it.
:   simon

    I think we can create the shadow association in null_nresolve().  The 
    resolver is called by the lookup code as necessary.  We don't actually
    have to create any shadow associations at the time we do the allocation
    of the null layer namecache record because it will be flagged as
    NCF_UNRESOLVED (meaning 'unknown state') until it is resolved.  It is ok
    for the shadow association to not exist while the record is in that state.

    Resolving the record means that null_nresolve() will be called.
    It is true that the higher layer namecache record will be locked on
    entry to null_nresolve(), but all that means is that we have to unlock
    it in order to create the association, then relock it, or possibly even
    optimize the operation by attempting to obtain the lower layer's lock
    non-blocking first (since most of the time the lower layer won't be

    The namecache code also has a retry mechanism which we can leverage
    if need be.  This mechanism is used by cache_resolve() if the 
    VOP_NRESOLVE() call returns EAGAIN.  I created the retry mechanism
    to deal with reconnecting disconnected NFS namecache records on the
    server but the code can also be used if we hit any weird shadowing


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]