The points are good, but I certainly don’t want inotify features to be gating the VFS layer. IMO inotify is good at what it does. If you want to know about absolutely everything going on for a given filesystem, maybe you want to implement the filesystem itself (fuse, e.g.).
IIRC (and I was involved in higher level filesystem libraries when this stuff was going into the kernel - but that was a long time ago) dnotify and inotify were designed with the constraint that they couldn’t impose a significant performance penalty, the logic being that the fs operations were more important than the change notification. If watching changes is as important or more important than io performance another mechanism like a fuse proxy fs or strace/ptrace makes sense.
fuse is how tup keeps track of dependencies, although I think it also will attempt to use library injection when that’s not availible.
That’s awesome. I’ve tried experimenting with ptrace/strace to ensure correct dependency declaration and it’s a real pain to get right.
I have yet to try it out, but I’m definitely using it in my next project.
Thing is, FUSE is slower, buggy (I’ve had kernel panics) and less flexible. A native way to track file system operations in a lossless manner would be really nice to have on linux.
I have to agree with Helge Bahmann’s comment on the blog. inotify isn’t designed to solve the problem the author is trying to solve, and there are good reasons why it can’t behave the way the he wants it to.
If the author wants to see what a process is doing with the file system he should use something like strace and monitor the fs related calls. inotify doesn’t even tell which process triggered the fs change, so it doesn’t solve his problem.
I think the typical use is something like backup software that wants to know about new files, in which case you don’t know which processes to watch.