On 9/6/05, Robert Watson <[EMAIL PROTECTED]> wrote: > > 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".
Thanks for the info detailed herewith. My purpose is similar to lsof utility. It looks up the namecache and provides a list of open filenames for a given process and it turns out that lsof is cross-platform and quite popular. Just curious -how huge would the name cache be -if all open files had a vnode<-->pathname mapping recorded? The mappings can be dropped when the file descriptor's reference count drops to 0. regards -kamal > 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 > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
