On Jul 27, 2009 20:23 +0100, Jamie Lokier wrote: > Andreas Dilger wrote: > > I think the "fanotify doesn't generate more fanotify events" makes the > > most sense. Given that the open will be done in the kernel specifically > > due to fanotify, this doesn't actually allow the listener to open files > > without detection (unlike the "O_NONOTIFY" flag would). The fanotify > > "opens" would only be in response to other processes opening the file. > > Nice idea (if I understand it) - the file descriptors opened by > fanotify wouldn't cause fanotify events? Effectively having an > in-kernel O_NONOTIFY flag which can't be set from userspace? Right. > 'if you have fanotify open, you don't create other fanotify events' is > too severe - it means you can circumvent fanotify entirely for > everything your process does by just opening a fanotify socket and not > using it, which is clearly worse than having an O_NONOTIFY flag. That isn't what I meant... It was only "operations on fanotify file descriptors don't produce further fanotify events", otherwise madness ensues. > What's wrong with fanotify-using applications generating events when > they modify files themselves? > > An example was given where app A gets an event and modifies the file, > then app B gets an event and modifies the file, and app A... cycling. > > But if you have two "virus checker" style applications fighting over > modifying the same file without locking, you have much bigger problems > already. There's nothing to gain by fixing the fanotify cycle. I don't think they are fighting over modifying the file, they are generating an endless stream of events for each other to process. I don't think locking will help. It's the same as e.g. having verbose kernel debug messages related to filesystem/block IO going to /var/log/messages on the filesystem you are monitoring. After the first (external) IO, it is logged to disk, which causes an IO to the filesystem, which is logged to disk, which causes an IO... There has to be some way to NOT generate any events on the files that you are monitoring. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
