Date: Tue, 6 Sep 2005 19:24:35 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: kamalp@acm.org Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Sergey Uvarov <uvarovsl@mail.pnpi.spb.ru>, freebsd-hackers@freebsd.org Subject: Re: vn_fullpath() again Message-ID: <20050906191929.E78038@fledge.watson.org> In-Reply-To: <ac7deb5050906082961c84a44@mail.gmail.com> References: <E1ECemU-0004dI-00.shmukler-mail-ru@f26.mail.ru> <868xyack37.fsf@xps.des.no> <ac7deb5050906082961c84a44@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050906191929.E78038>