vn_fullpath()

[Robert Watson]

On Mon, 21 Feb 2005, Igor Shmukler wrote:

> > So the first thing to do is to decied what your requirements are: are you
> > willing to fail in the edge cases like the above?  If so, life is a lot
> > easier :-). 
> 
> I guess I am willing to fail :). Perhaps in some distant future, we will
> look into the nasty corner cases, but for now, as long as I get a name,
> it will do. We don't even mind the hardlinks so much, but we cannot
> afford to use existing vn_fullpath() because it does not guarantee
> "anything".

There are a couple of issues to look at, if we can allow some obscure edge
cases to fail, but want it to "generally" work:

(1) File systems that don't use the centralized name cache facility, such
    as procfs and devfs.

(2) What to do when useful paths fall out of the name cache.

I think the answer to (1) is to let those file systems simply provide a
vnode operation to answer the question: they're almost always synthetic
file systems, or they would be using the cache.  So I'm almost thinking: 

    VOP_GETPATH(vp, char *buf)

The call would say to the file system "Tell me the path from your root to
the vnode in question".

On the (2) front, I think there are a couple of possibilities -- the
decision to let intermediate paths fall out of the name cache is an
explicit design choice to reduce the vnode burden on the system.  We can
either back off that design choice forcing intermediate nodes to generally
remain in the cache, or we can accept it and address it.  My leaning is to
add a new rule: "the last directory used to reach a file must not fall out
of the cache if the file hasn't fallen out of the cache" -- with this in
place, we can generate path names for most objects by walking back up the
tree if elements are missing, either directly, or by asking the file
system using the above call.  It's the last step from the file back to a
parent directory that is the hardest.  Alternatively, we can back off
dropping the intermediate nodes and see to what extent that hurts vs.
helps.

Robert N M Watson