Design of vn_getpath (was Re: fsevents oddities)
Design of vn_getpath (was Re: fsevents oddities)
- Subject: Design of vn_getpath (was Re: fsevents oddities)
- From: Hamish Allan <email@hidden>
- Date: Fri, 3 Jun 2005 17:51:45 +0100
On 2 Jun 2005, at 05:16, Mike Smith wrote:
But there is no file /Users/hamish/bar/foo.txt, and nor has
there ever been, so something is wrong with the caching.
Whatever part of the system is caching foo.txt shouldn't be
doing so once the write to bar/bar.txt has happened. And why,
even after I've removed foo.txt and imported bar/bar.txt, hasn't
it been updated yet in line 20?
foo.txt and bar.txt are the same file; it just has two names.
Only one of those names can be cached; in this case, it's the one
by which the file was first looked up.
I really meant to imply the question, "why would the cache not be
updated with the name by which the file was *most recently* looked
up?"
Why would any one name be more correct than any other? It's a
losing game, unfortunately.
Specifically, I have demonstrated a case where the parent vnode is
updated without updating the cached filename, leading to a never-
existent path /Users/hamish/bar/foo.txt, in which MRU would be more
correct.
Solitaire is also a losing game, but there are ways that you can play
it which maximise your chances of winning.
Whereas with the current situation you remember that the node was
once looked up as bar.txt under foo, and provide that pathname
whether or not it still exists (even if a currently existing
pathname, e.g., quxx.txt under baz, has been used more recently).
This is slightly less work for considerably less (indeed, arguably
negative) return.
It's O(1) work rather than O(N) work, and for the common case (i.e.
where nobody is using hardlinks) it works well enough.
For the common case (i.e. where nobody is using hardlinks) my
suggestion is O(1). "It works well enough" is assuming the consequent
-- this thread is about the cost/benefit tradeoff, and I think that
misinformation is arguably less useful than no information.
I think that "all that" is perhaps touchingly naive, but yes in
theory there is no reason why multiple parent associations could
not be maintained, however this is a lot of work for overall very
little return.
You might say the same about providing *any* sort of vn_getpath()
operation.
As far as I can tell I am not suggesting rocket science? Or am I
underestimating the cost of implementing what I would consider to
be a decent benefit?
In providing *any* pathname for an extant vnode, the kernel is
already making a dangerous guarantee. Encouraging further use of
the interface just makes the consequences worse.
All that the current implementation guarantees is that at some point,
components of the returned path were components of a path or paths
that once existed to a given vnode. Not even that the returned path
was ever a path to the given vnode.
What my suggestion guarantees is that at calling time, there existed
such-and-such a path to a given vnode. Where's the danger in that?
At the very least, surely the current caching mechanism should
freshen the cache more often than it does?
The tradeoffs between MRU and MOU are so bad that first-come is, in
the end, no worse.
I'm not sure I understand how MOU is relevant to this.
Best wishes,
Hamish
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden