The fanotify API - corrections [LWN.net]

The fanotify API - corrections

Posted Jul 3, 2009 1:28 UTC (Fri) by jlokier (guest, #52227)
In reply to: The fanotify API - corrections by eparis
Parent article: The fanotify API

Oh dear. If it has the same silly open-the-whole-tree problem before you know you have all change events, it's *not* suitable for non-disk bashing indexers.

And it's not suitable for non-disk bashing virus checkers / tripwire-like programs either.

Disk bashing is what happens each time you restart or remount a filesystem. Just to traverse the directory tree to set inotify events on it.

Last time I discussed this with Tracker folks, their answer was "most users don't have a lot of files, you are unusual as only developers typically have lots of files and a rich directory tree".

Thanks, guys. What happened to doing things right?

Occasionally a thoughtful response emerges: "but you can't notify all the parent directories if a hard-linked file is modified". A natural gut instinct, but mistaken.

inotify already determines parent directories of all files, including linked ones, in a path-based manner: when you change a file, it follows the path used to access the file to notify listeners on the containing directory. Linked files can be monitored accurately by either watching the inode itself, or watching all known parent directories, which you can verify from the link count and bind-mount points - a userspace problem.

So do the obvious thing, and notify listeners on all containing directories up the whole path used to access the file. (And provide an IN_ATTRIB event when the link count is incremented by linking - seen by watchers on the source path - currently that omission makes directory inotify unsuitable for verifying lack of file changes even with deep tree traversal at the moment).

Then userspace has enough to watch whole trees with the same fidelity as it can now, but much more efficiently - no massive traversal required. No disk bashing. It'd be nice to catch up with Windows 2000 in this department.

to post comments

The fanotify API - corrections

Posted Jul 3, 2009 11:04 UTC (Fri) by brother_rat (subscriber, #1895) [Link] (4 responses)

I think you've misunderstood things. Try reading the original announcement and you'll see how simple it is to watch the entire file system. In particular:

fanotify has two basic 'modes' directed and global. fanotify directed works much like inotify in that userspace marks inodes it is interested in and gets events from those inodes. fanotify global instead indicates that it wants everything on the system and then individually marks inodes that it doesn't care about. They both have the same userspace interface and rely on the same fsnotify in kernel infrastrucute (although the infrastructure did have to modified to support the global listener concept)

Also look at the example program at the end of the e-mail.

The fanotify API - corrections

Posted Jul 4, 2009 9:43 UTC (Sat) by jlokier (guest, #52227) [Link] (3 responses)

The global mode does work if you want to monitor everything, system-wide, but it is too broad-scope if you just want to monitor, say, $HOME. Or /var/www/databases. Etc., you get the idea. There are many good reasons to monitor everything below a particular directory. Especially on multi-user systems. An off the wall example: Recursively monitoring changes below $PWD would be useful for speeding up programs like Make and Git between invocations. Recursively monitoring $HOME is appropriate for personal indexers on multi-user systems.

So the obvious thing to do is improve inotify to provide recursive notifications, instead of Yet Another API to a slightly different mix of the same features. IN_RECURSIVE: "notify this directory of events occuring on any path below the directory, not just immediately below the directory". There you go. Making it efficient is left as an exercise :-) (hint: lazily propagate flags up and down the dentry tree)

That's notifications. The other part is blocking operations on files - the filtering part. We already have a mechanism for that, too: leases. The F_SETLEASE API is clearly not suitable, but the underlying lease mechanism is close. Suggestion: return a leased file descriptor alongside an inotify event if IN_LEASE_* flags are set. Use F_SETLEASE or something like it to release a lease, granting or denying permission.

In it's present form it is sure to be rejected due to the very strange and unnecessary API, and it which looks like it was written by people who did not read the history of inotify's inclusion into the kernel. inotify has it's own system calls because the original version was rejected on l-k, and told to use system calls because it's not a device or socket.

As a small incremental change to inotify, it's much more likely to be accepted, and it's also much more likely to be useful for applications you haven't thought of.

There might still be a reason to add a netlink socket API as well (though I can't think of one), but if so it should be a general addition to inotify, not a complete replacement which happens to be like inotify in some ways and different in others.

We already have F_NOTIFY, inotify and F_SETLEASE. We don't need yet another slightly different but nearly the same thing, which happens to be useful for a tiny set of applications but still very limited in arbitrary ways, when a little incremental improvement to inotify would be both cleaner and useful for a lot more applications.

Don't get me wrong, inotify has flaws, but together with leases, it's not far off what the fanotify-using applications need. I strongly advocate fixing them, rather than starting again.

This discussion should be on linux-fsdevel...

The fanotify API - corrections

Posted Jul 10, 2009 23:53 UTC (Fri) by efexis (guest, #26355) [Link] (2 responses)

The global method should work fine then surely; set a global listener, and ignore any notifications where the pathname doesn't begin with your required string (eg, '/home/'). If you're worried that that'll get triggered more often that it need be (esp if you want different trees monitored for different purposes) then it's not much work to create a plugable super-server that listens globally and hands you the notifications you're interested in... then everyone can have their own monitoring process for their own home directory, without there being several processes woken with each file opened... and the super-server could do extra things like make sure the monitor has read access to the file opened before handing it the FD.

Also, the fact that inotify and dnotify code can be dropped from the kernel and replaced by slim wrappers around these calls instead makes sense from a code tidying/maintenance point of view. If you really think that inotify is the interface you want to use, but want it to be able to watch entire sections of the filesystem (a 'recurse' flag), then as inotify will become a wrapper around this interface that will allow you to do it, it's really not going to be hard for you to add that feature to it.

The fanotify API - corrections

Posted Jul 14, 2009 22:30 UTC (Tue) by icculus (guest, #4942) [Link] (1 responses)

"...ignore any notifications where the pathname doesn't begin with your
required string (eg, '/home/')"

I don't see a way to get an actual path from this API, just the file
handle.

The fanotify API - corrections

Posted Jul 18, 2009 7:22 UTC (Sat) by efexis (guest, #26355) [Link]

Oh yeah it certainly does look like that... it can't possibly be true though, after all, how would a virus scanner warn of which file is infected without path information? How would it move or delete the file without knowing what directory it's in? It would also make it useless for an indexing system, as the indexing system is surely a file contents/metadata <--> file path lookup, so without the path, it's useless. You couldn't tie it to git or anything to monitor for code changes because you wouldn't know what file's being changed.

Is there no file descriptor path lookup method? Would it not appear in /proc/self/fd/? There's gotta be a way otherwise surely this patch would just be laughed out.