inotify? [LWN.net]

inotify?

Posted Sep 2, 2008 7:42 UTC (Tue) by dlang (guest, #313)
In reply to: inotify? by liamh
Parent article: TALPA strides forward

short answer, inotify doesn't scale.

inotify works fairly well if you have a small set of files or directories that you want to look for changes in, but it doesn't work if you want to find out about changes throughout the filesystem

to post comments

inotify?

Posted Sep 3, 2008 2:40 UTC (Wed) by liamh (guest, #4872) [Link] (2 responses)

OK. Then wouldn't it make sense to make this effort be an inotify next generation (robust and scalable) project, thereby avoiding the issue of the eventual application(s)? I use inotify now for something which has nothing to do with virus scanning, and I can imagine other applications as well, so perhaps there is a need for this anyway, quite apart from the scanners. It seems like a bad idea to have two independent partially overlapping subsystems in the kernel.

Liam

inotify?

Posted Sep 3, 2008 8:21 UTC (Wed) by njs (subscriber, #40338) [Link] (1 responses)

There's been talk of such things (OS X has a similar scalable mixed kernel/user-space notification service that it uses for things like indexing), and it absolutely should be created for Linux -- but TALPA has requirements well beyond that. Blocking read(2) until some other userspace process has woken up and okay'ed things is *way* outside the scope of an inotify-alike!

inotify?

Posted Sep 3, 2008 18:51 UTC (Wed) by jlokier (guest, #52227) [Link]

Actually it's not so far away from inotify.

We have leases in fcntl() F_SETLEASE, they go alongside dnotify in fcntl() F_NOTIFY.

inotify could similarly benefit from an an ilease extension, as well as further scalability improvements. (inotify was designed to improve on dnotify in many ways including scalability; it's a shame it stopped half way).

That's blocking readers right there.