vn_fullpath() again

[Robert Watson]

On Tue, 6 Sep 2005, Kamal R. Prasad wrote:

>> one or more names and none of these names are more correct or 
>> authoritative than any of the others. If a user does 'ln /bin/ls /tmp' 
>> (assuming /bin and /tmp are on the same filesystem), it may be obvious 
>> to you that /bin/ls is the "real name" is /tmp/ls is just an alias, but 
>> it is not obvious to the kernel. In fact, the kernel is unable to see 
>> any difference at all between these two names.
>
> Yes -but when a user requests a mapping of vnode to pathname, he is 
> asking in the context of files he has accessed (recently). In this 
> context, the name cache does suffice -but unfortunately not every unix 
> variant provides access to it. regards -kamal

I suppose it depends a lot on what it is you plan to use the path for. 
For the purposes of audit, we've concluded that in fact we don't even need 
to re-generate the path, we'll simply use the path as requested by the 
user when a path was entered.  I.e., our definition of "recently" is 
"immediately".

Other less immediate definitions of "recently" are a bit of a problem 
though, since file access often happens over the course of months or years 
after the initial lookup took place, at which point things an be very, 
very stale.  For example, programs often open log files and hold them open 
for extended periods; likewise libraries, data files, directories, and so 
on.  How recently is recently?  One tenth of a second?  One second?  Ten 
seconds? Ten minutes?  Ten hours?  Ten days?  Ten weeks?  Ten years? 
FreeBSD operates on all of these time scales...  Right now the FreeBSD 
name cache reliably returns paths for a short period of time after they 
are looked up -- the further you get from the initial lookup, the less 
reliable they become.  The reliability is largely affected by two factors: 
the fact that this is a cache, and things fall out of the cache, and the 
fact that the name space is quite mutable and invalidates entries in the 
cache.

The third case of unreliability which is addressable is cases where 
synthetic file systems simply don't use the cache -- i.e., devfs.  My 
proposal for dealing with this is simply to allow those synthetic file 
systems to return a name if they can.  I think modifying them to use the 
name cache doesn't make sense however, since in many cases you don't want 
to cache: i.e., lookups of /dev/ptmx with the pts driver, or 
/proc/curproc, and caching would defeat the point.

Robert N M Watson