John Levon wrote:
On Thu, May 04, 2006 at 08:46:01AM -0700, Bart Smaalders wrote:
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 am not sure if 'inotify' can watch an entire directory tree? Is
Beagle using inotify
currently to watch directory tree? What are Beagle's requirements? May
be we should
understand that better.
Like Bart mentioned how does it resolve access permissions along the path?
What about nested mount points?
If the events have to be queued, then we will have to set the size(# of
events)
of the queue along with the watch request. Would this address the needs
completely?
Implementing this would complicate the interfaces and probably open up
more issues.
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.
We could have this for all the event types we support. If the event is
set in the
notification, it would mean that event has occurred since the last time
it was
checked. The application has to check/verify it once it receives the event.
With this approach there will not be a need for queuing events.
-Prakash.
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
