nullfs stabilization I
dillon at apollo.backplane.com
Tue Jan 10 18:25:43 PST 2006
:Matthew Dillon wrote:
:> (2) Do not have a shadow callback. Instead have null_nresolve()
:> call a new function, cache_shadow(), which creates the relationship
:> between the upper and lower layer namecache records. Only
:> null_nresolve() would need the added sophistication.
:While I completely agree with the rest of your proposals, I see one
:Imagine you create a file in the NULLFS layer. For this the code
:cache_lookup()s and then gets a locked namecache entry, which might not
:be resolved yet (new file, not in cache). This would mean that we have
:a locked record but no shadow association. At the same time another
:process can race in the shadowed layer and as well lock the record which
:is the counterpart to the already locked NULLFS namecache entry.
:Not good. This is the reason why I used this callback in the first
:place. Do you have a better method to do this?
cache_lock would create the namecache record in the lower layer
(recursively), and then operate in the same manner as if it exited in
the first place.
This could be done with a VFS function, but I think its probably better
to make it a separate registration call to create the association between
layers as part of the struct mount. There are two situations that need
to be handled:
(1) The situation you mention, where locking a higher layer's namecache
record also requires that the lower layer's namecache record be
created (if necessary) and locked.
(2) The situation where the lower layer's namecache record is operated
upon (such as in a create, delete, or rename), requiring higher
layer's namecache records to be (at least) invalidated.
In addition, consider the case where you might have ten NULLFS
mounts layered on top of the same base filesystem!
The nullfs layer would thus have to register the relationship as part
of the mount sequence. Something like:
That might be all that is required for the cache_*() functions
(primarily cache_lock()) to be able to figure out what to do.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel