DragonFly kernel List (threaded) for 2006-01
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: nullfs stabilization I
: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.
:
:cheers
: 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
locked).
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
cases.
-Matt
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]