Date: Mon, 21 Feb 2005 12:13:19 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: rwatson@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org Subject: Re: Re[2]: vn_fullpath() Message-ID: <200502212013.j1LKDJPT042188@gw.catspoiler.org> In-Reply-To: <Pine.NEB.3.96L.1050221155912.30319C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502212013.j1LKDJPT042188>