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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
