Re: vn_fullpath() again
From: Kamal R. Prasad (kamalpr_at_gmail.com)
Date: 09/07/05
- Previous message: Matthew Dillon: "Re: vn_fullpath() again"
- In reply to: Robert Watson: "Re: vn_fullpath() again"
- Next in thread: Robert Watson: "Re[2]: vn_fullpath() again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 7 Sep 2005 10:48:12 +0530 To: Robert Watson <rwatson@freebsd.org>
On 9/6/05, Robert Watson <rwatson@freebsd.org> 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 "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Matthew Dillon: "Re: vn_fullpath() again"
- In reply to: Robert Watson: "Re: vn_fullpath() again"
- Next in thread: Robert Watson: "Re[2]: vn_fullpath() again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
