Glynn Foster wrote:
Yeah, currently Beagle only indexes a relatively small amount of
per-user data, generally in $HOME - however, as has been mentioned,
it's probably one of the first proper use cases of inotify.
I'd suggest that it's definitely worth looking at what inotify does -
given that there seems to have been a lot of churn with
dnotify/inotify/FAM/gamin/ etc.., there's probably some implementation
lessons to be learned from our Linux neighbours [some of
http://kerneltrap.org/node/3847 might be interesting reading].
FILE_CLOSE_WRITE is missing from the list of events posted previously
that is apparently useful, as suggested by some GNOME developers.
Yes, I have looked at some of the issue with 'dnotify' that got addressed
by 'inotify' and also some of the issue with inotify.
Here is another pointer which lists some issues with 'inotify'. These
may have
been addressed already with the later version of inotify.
http://manic.desrt.ca/inotify
Proposed interfaces:
- Unlike the 'inotify' interfaces, which uses 'ioctls' to a device, our
interfaces will be based on the existing Event ports framework. The
events
will be delivered to a specified 'Event port'(which is an fd).
The Event port can receive events from multiple sources. Currently
available event sources in Solaris 'poll, aio, timer, user,
message queue(this was recently integrated)'.
More event sources can be added.
Ex,
if the application needs to wait on a 'poll' event and also receive
file events
notifications, it can receive both these types of events on one Event
port.
- The application does not have to open the file/directory being watched.
Therefore it will not prevent the file from being deleted or
unmounting the filesystem. These where issues with 'dnotify'.
- If the file system gets unmounted, it will automatically de-register
the event notification and send an event indicating that.
It can also send a 'file deleted event' when watching a file which
gets deleted.
- A pointer to some user data can be passed in when registering file
event notication.
The user data will be returned along with the event notification.
This was something
missing with the inotify interface.
I think 'inotify' returns something called 'watch descriptors' when
registering the watches.
They had some issue with 'watch descriptors' being reused that would
cause confusion in
identifying the received events. This issue may have been addressed
already with their
new version.
This problem should not exist with the event ports interface since a
user data pointer will
be returned with the event. The application can differentiate the
events based on that.
- To de-register or to re-register, the object(file) needs to be passed
again. But the
file name could disappear(get removed) from the directory. To
accommodate this,
we could change the passed in object to a structure which will
include the filename.
Once it gets registered, the system can return an unique id. So
subsequent actions
(de-register, re-register), we depend on this 'id'.
Ex.
file_event {
uintptr_t id; /* id returned after registering */
int len; /* length of the file name */
char fname[0]; /* filename */
}fobj;
So, now the interface will be
port_associate(port, PORT_SOURCE_FILE, (uintptr_t)&fobj, ... )
So this 'fobj' structure can be passed to de-register(port_dissociate)
or re-register(port_associate again) the file events.
FILE_CLOSE_WRITE - What is the purpose of this event? If it is
found to be useful, we could include it.
Rgds,
-Prakash.
Glynn
Glynn
Does this mean we don't get told /what/ got created? Is an
application that
wants to know "what files are disappearing/appearing under
/foo/bar/?" going
to have to readdir() the whole directory every time it gets an event?
Otherwise we get into the queued event problem; what happens if the
application is watching a directory w/ a million files, and someone
does
rm * in that directory? Do we generate a million events? Clearly
there
are limits to the number of events we can queue in the kernel, esp.
since the application isn't obligated to read them in a timely fashion.
Forcing a (recursive!) readdir() every time can't scale either; it
just pushes
the problem out all the userspace apps. Perhaps a compromise approach
would
work, so at least the readdir() cost is amortized; i.e. give names up
to a
particular limit.
Or how do you expect Beagle to be able to work nicely? Is this just
going to
remain something explicitly unsupportable?
I'd rather have a model like signals; multiple file writes are
combined into one event until that event is read by the application;
any subsequent writes generate another event.
Would work fine for modifications, yes.
I see this as very useful to avoid the {sleep(); stat() } loops we
often
see. It's not a mechanism to insert an application as an synchronous
interposer into the filesystem VOPS.
I wasn't trying to suggest it was. Synchronisation is neither needed nor
wanted.
The nscd could use this to watch for modifications to configuration
files rather than stat'ing them before each cache lookup.
I wasn't suggesting that a non-recursive approach doesn't solve a
whole class
of such situations; it does. In fact, I was merely trying to raise
awareness of
what applications like Beagle actually need in terms of
notifications. If it's
really too hard to do, that's a pity.
regards,
john
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
