nullfs stabilization I
Simon 'corecode' Schubert
corecode at fs.ei.tum.de
Sat Jan 14 05:46:52 PST 2006
Matthew Dillon wrote:
Let me suggest an alternative approach. The real problem here is
always going to be locking of the namecache record(s). The creation
aspect of the namecache record(s) (the shadow chain) is trivial since
an upper layer can simply do the translation and ask for the lower
layer. In the absense of locking, we do not have any deadlock issues
with this approach. The code would also be more readable.
So perhaps the solution here is to create an auxillary locking structure
that all related namecache records can share. This locking structure
would serve to 'glue' the namecache records in the chain together.
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
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low â¬â¬â¬ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
More information about the Kernel
mailing list