From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 7 05:25:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21C6D16A41F for ; Wed, 7 Sep 2005 05:25:16 +0000 (GMT) (envelope-from kamalpr@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E65F43D45 for ; Wed, 7 Sep 2005 05:25:15 +0000 (GMT) (envelope-from kamalpr@gmail.com) Received: by xproxy.gmail.com with SMTP id i27so631810wxd for ; Tue, 06 Sep 2005 22:25:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=koF+H96BaGQlGDxtyeaxG9n8O2fX6ND0xmLDIYAOLhJFASe1UwnkddfWeVrnmTSl9AuhAdH0rBLexEFG7BhojSa8QnLdgrfUfUaC+lhlToV/viE71NkrQovmY9jV6LgdQHhkCmqXn6f2BevguptsMINLT6lbcewjwuJUpir9GXc= Received: by 10.70.26.3 with SMTP id 3mr151134wxz; Tue, 06 Sep 2005 22:18:12 -0700 (PDT) Received: by 10.70.23.12 with HTTP; Tue, 6 Sep 2005 22:18:12 -0700 (PDT) Message-ID: Date: Wed, 7 Sep 2005 10:48:12 +0530 From: "Kamal R. Prasad" To: Robert Watson In-Reply-To: <20050906191929.E78038@fledge.watson.org> Mime-Version: 1.0 References: <868xyack37.fsf@xps.des.no> <20050906191929.E78038@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Sergey Uvarov , freebsd-hackers@freebsd.org Subject: Re: vn_fullpath() again X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2005 05:25:16 -0000 On 9/6/05, Robert Watson 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 >