It would indeed be very cool if dnotify could say which inode has been
updated. The problem I have with FAM is that notifications aren't
immediate, which makes it useless for my fast dynamic web server
application. For that, notifications have to be strong enough to
support the rule "if I have not received a dnotify _now_, then my cached
stat() result is valid for files in that directory _now_".
> I don't have much of a clue about the kernel, so please excuse my ignorance,
> but the imon patch seems pretty unintrusive to me and enables more
> fine-grained file change notifications than dnotify. Also, FAM can monitor
> NFS-mounted directories with almost no network overhead when it's also
> running on the server.
Ah, thanks, I didn't know about imon.
The imon API is nice -- I could use that and more efficiently than
dnotify. (I can't use FAM because of notification delays, but the imon
device is just right).
Unfortunately the implementation is rather intrusive. As it says, it
implies a performance hit on every file operation on all files, if any
file is being monitored. So I can see it being disabled on high
performance servers, which is where I need it.
A fusion of imon and dnotify would be good:
- absolute minimum impact on file operations: a small inline check,
per inode not globally, as dnotify does now.
- imon-style hash table used for inodes that aren't in core, so you
can monitor a large number of files individually without pulling
their inodes into core. When inodes are brought into core then the
hash table entries are moved to the in core inode, and vice versa.
(Not sure about the reliability of hashing on inode numbers,
though -- some filesystems don't provide reliable inode numbers).
- dnotify-style lists of monitoring requests attached to in core
inodes.
- per-process monitoring sets, as dnotify does.
- imon-style precision notification of individual files, including
reliably monitoring files which are hard linked in different
directories.
- dnotify causes files to notify their parent directory (yes it's
ambiguous with hard links). In a per-file scheme, one possible
flag on a file's inode would be "notify my parent directory". I
see no reason not to extend that to "I am a directory. If I
receive a notification from a child, notify _my_ parent directory",
for those occasions when you'd like to monitor a whole directory
hierarchy without having to do the equivalent slow disk accesses of
"find -print" on it first.
- guarantee that the event will be sent to the monitoring process
immediately after the operation which triggers the event, and
before the operation releases inode semaphore, if it has it -- so
that monitoring processes can depend on "if I haven't received a
notification then my stat() cache is still valid".
Some ideas. I would really like this to be usable with my idea for a
fast dynamic web server, which is also a "make" server, so I'm willing
to put some work in here.
Feedback appreciated,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/