Hey,
John Levon wrote:
On Thu, May 04, 2006 at 08:46:01AM -0700, Bart Smaalders wrote:
http://beaglewiki.org/Main_Page
as well as some other GNOME things, apparently.
This cannot scale.
It doesn't necessarily need to scale; from my understanding, Beagle is more
about watching ~/Documents/ than big lots of data.
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.
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
