John Levon wrote:
On Wed, May 03, 2006 at 07:31:08PM -0700, Prakash Sangappa wrote:
If you where to watch for events on an entire directory tree, what types
of events that would be?
Presumably there would be some way to specify, but file creation/deletion would
be the most obviously useful events.
How would this be useful?
Beagle wants it, I think:
http://beaglewiki.org/Main_Page
as well as some other GNOME things, apparently.
This cannot scale. I cannot expect a single application to able to
receive events for all modifications to a 10 TB filesystem in heavy use.
Clearly, the app will need a backup plan. And if this is a search app,
what about file modifications?
can be to just a watch on the directory "/etc". The FILE_CREATE event would
mean that a file or a directory was created under "/etc". Once the
application gets this event, it can go and check if the file got created.
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.
How about the file modification event? Do we generate them on each
write? On each read?
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. This would work equally well
for directories.
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 don't know how to do this w/o
having each application write code to cope with the case where the
kernel generates events faster than the application can handle them.
A file manager such as Nautilus could use this to avoid the following
loops:
/1: pollsys(0x08270888, 5, 0x08047058, 0x00000000) = 0
/1: xstat(2, "/home/barts/Desktop", 0x08046F08) = 0
/1: ioctl(4, I_NREAD, 0x08046FD0) = 0
/2: pollsys(0x0843FCA0, 10, 0x00000000, 0x00000000) (sleeping...)
/1: pollsys(0x08270888, 5, 0x08047058, 0x00000000) (sleeping...)
/1: pollsys(0x08270888, 5, 0x08047058, 0x00000000) = 0
/1: xstat(2, "/home/barts/Desktop", 0x08046F08) = 0
The nscd could use this to watch for modifications to configuration
files rather than stat'ing them before each cache lookup.
The model of watching all events in a filesystem hierarchy would
seem also to have significant security issues; can an application
use this to watch the creation of files in someone else's 0700
directory?
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
