From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 21 20:13:28 2005 Return-Path: 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 9EED316A4CE; Mon, 21 Feb 2005 20:13:28 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3006643D41; Mon, 21 Feb 2005 20:13:28 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j1LKDJPT042188; Mon, 21 Feb 2005 12:13:23 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200502212013.j1LKDJPT042188@gw.catspoiler.org> Date: Mon, 21 Feb 2005 12:13:19 -0800 (PST) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org Subject: Re: Re[2]: vn_fullpath() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 20:13:28 -0000 On 21 Feb, Robert Watson wrote: > > On Mon, 21 Feb 2005, Igor Shmukler wrote: > >> > So the first thing to do is to decied what your requirements are: are you >> > willing to fail in the edge cases like the above? If so, life is a lot >> > easier :-). >> >> I guess I am willing to fail :). Perhaps in some distant future, we will >> look into the nasty corner cases, but for now, as long as I get a name, >> it will do. We don't even mind the hardlinks so much, but we cannot >> afford to use existing vn_fullpath() because it does not guarantee >> "anything". > > There are a couple of issues to look at, if we can allow some obscure edge > cases to fail, but want it to "generally" work: > > (1) File systems that don't use the centralized name cache facility, such > as procfs and devfs. > > (2) What to do when useful paths fall out of the name cache. > > I think the answer to (1) is to let those file systems simply provide a > vnode operation to answer the question: they're almost always synthetic > file systems, or they would be using the cache. So I'm almost thinking: > > VOP_GETPATH(vp, char *buf) > > The call would say to the file system "Tell me the path from your root to > the vnode in question". > > On the (2) front, I think there are a couple of possibilities -- the > decision to let intermediate paths fall out of the name cache is an > explicit design choice to reduce the vnode burden on the system. We can > either back off that design choice forcing intermediate nodes to generally > remain in the cache, or we can accept it and address it. My leaning is to > add a new rule: "the last directory used to reach a file must not fall out > of the cache if the file hasn't fallen out of the cache" -- with this in > place, we can generate path names for most objects by walking back up the > tree if elements are missing, either directly, or by asking the file > system using the above call. It's the last step from the file back to a > parent directory that is the hardest. Alternatively, we can back off > dropping the intermediate nodes and see to what extent that hurts vs. > helps. I seem to recall that DragonFly keeps the intermediate nodes.