Date: Wed, 7 Sep 2005 10:48:12 +0530 From: "Kamal R. Prasad" <kamalpr@gmail.com> To: Robert Watson <rwatson@freebsd.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: <ac7deb505090622187628dcbd@mail.gmail.com> In-Reply-To: <20050906191929.E78038@fledge.watson.org> References: <E1ECemU-0004dI-00.shmukler-mail-ru@f26.mail.ru> <868xyack37.fsf@xps.des.no> <ac7deb5050906082961c84a44@mail.gmail.com> <20050906191929.E78038@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/6/05, Robert Watson <rwatson@freebsd.org> wrote: >=20 > On Tue, 6 Sep 2005, Kamal R. Prasad wrote: >=20 > >> 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, bu= t > >> 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 >=20 > 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 nee= d > 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". =20 Thanks for the info detailed herewith. My purpose is similar to lsof utility. It looks up the namecache and=20 provides a list of open filenames for a given process and it turns out that= =20 lsof is cross-platform and quite popular. Just curious -how huge would the name cache be -if all open files had a=20 vnode<-->pathname mapping recorded? The mappings can be dropped when the=20 file descriptor's reference count drops to 0. regards -kamal =20 > Other less immediate definitions of "recently" are a bit of a problem > though, since file access often happens over the course of months or year= s > 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. >=20 > 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. >=20 > Robert N M Watson >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac7deb505090622187628dcbd>