vn_fullpath()

[Don Lewis]

On 21 Feb, Robert Watson wrote:
> 
> 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.

I seem to recall that DragonFly keeps the intermediate nodes.