Re: fsevents oddities (was Re: EVFILT_VNODES?)
Re: fsevents oddities (was Re: EVFILT_VNODES?)
- Subject: Re: fsevents oddities (was Re: EVFILT_VNODES?)
- From: Hamish Allan <email@hidden>
- Date: Wed, 25 May 2005 20:59:58 +0100
On 25 May 2005, at 18:03, Mike Smith wrote:
Ah, you have no idea the can of worms into which you blithely dip. 8)
I'm starting to get an impression!
There is a cache of names by which a vnode has been looked up; just
terminal name components. There is a child->parent relationship
maintained between a vnode and *one* parent in which it has been
looked up. This cache is built as a side-effect of the lookup
process, and persists in conjunction with the vnode cache. It's
not assembled en masse at any particular point in time.
Okay, I think I understand, but that still doesn't fully explain the
following behaviour:
1) $ mdfind hamishtest3
2) $ cat > foo.txt
3) hamishtest3
4) ^D
5) $ mdfind hamishtest3
6) /Users/hamish/foo.txt
7) $ mkdir bar
8) $ ln foo.txt bar/bar.txt
9) $ mdfind hamishtest3
10) /Users/hamish/foo.txt
11) $ cat >> bar/bar.txt
12) extra
13) ^D
14) $ mdfind hamishtest3
15) /Users/hamish/bar/foo.txt
16) $ rm foo.txt
17) $ mdfind hamishtest3
18) $ mdimport bar/bar.txt
19) $ mdfind hamishtest3
20) /Users/hamish/bar/foo.txt
In line 15 above, the last time the vnode for foo.txt was looked up
was via /Users/hamish/bar/, so that's where foo.txt is reported.
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?
The "path to vnode" is assembled by traversing these relationships;
there are transformations in the filesystem under which they cannot
be correctly maintained, and if a file is looked up by two
different paths, only one can be returned.
I think I understand this now. So to find out a file's name from its
vnode I ask the filesystem for a directory listing on the vnode in
its parent cache (and to find out its pathname I do that recursively).
I think that if the inverted index allowed multiple paths to be
stored for a vnode, the correct behaviour could be achieved. Of
course, some of my assumptions may not be correct. Any thoughts?
How would you know which path to return?
It would be good if you could return all of them: anything which
would want a vnode-to-path-lookup would surely benefit from having
them all? Instead of caching a single parent node, you would maintain
a linked list (or whatever) of all parent nodes.
I thought it might be possible to get similar functionality
without writing a VFS by having a daemon monitor the creation of
new directories (either in a particular place, or with Spotlight-
searchable attributes) and fill them with hard links to Spotlight
search results. To preserve the pathname of the files found, I
would create the full directory structure within the given folder;
I therefore wanted a way to monitor whether that structure had
changed, in order to halt any live updating of results and turn it
into a 'normal' folder
Attempting to run a user process in lockstep with the filesystem is
doomed from the start; don't do this.
Isn't that what Spotlight is: a user process attempting to run in
lockstep with the filesystem by means of the fsevents API?!
Build your structure lazily in response to user requests rather
than dragging the whole system down to a crawl.
I figured that essentially I would be using part of the filesystem as
a cache for search results, with the option of having that cache
updated live. So there would be as many threads alive as live smart
folders, but most of them would be idle most of the time. I hadn't
really considered that this would adversely affect performance
because I've never used a lot of smart folders, but it may not scale
well to other users.
You're definitely better off building your filesystem as a proper
VFS module.
I haven't found a great deal of information about how to go about
this. I have gleaned bits and pieces, like that I should bundle this
into a kext, without an explanation of how. Also I have little to no
idea about how to debug kernel code. Any pointers, anyone?
Thanks,
Hamish
_______________________________________________
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