Why Not dnotify and Why inotify

Everyone seems quick to deride the blunder known as "dnotify" and applaud a
replacement, any replacement, man anything but that current mess, but in the
name of fairness I present my treatise on why dnotify is what one might call
not good:

* dnotify requires the opening of one fd per each directory that you intend to
watch.
o The file descriptor pins the directory, disallowing the backing
device to be unmounted, which absolutely wrecks havoc with removable
media.
o Watching many directories results in many open file descriptors,
possibly hitting a per-process fd limit.
* dnotify is directory-based. You only learn about changes to directories.
Sure, a change to a file in a directory affects the directory, but you are
then forced to keep a cache of stat structures around to compare things in
order to find out which file.
* dnotify's interface to user-space is awful.
o dnotify uses signals to communicate with user-space.
o Specifically, dnotify uses SIGIO.
o But then you can pick a different signal! So by "signals," I really
meant you need to use real-time signals if you want to queue the
events.
* dnotify basically ignores any problems that would arise in the VFS from hard
links.
* Rumor is that the "d" in "dnotify" does not stand for "directory" but for
"suck."

A suitable replacement is "inotify." And now, my tract on what inotify brings
to the table:

* inotify's interface is a device node, not SIGIO.
o You open only a single fd, to the device node. No more pinning
directories or opening a million file descriptors.
o Usage is nice: open the device, issue simple commands via ioctl(),
and then block on the device. It returns events when, well, there are
events to be returned.
o You can select() on the device node and so it integrates with main
loops like coffee mixed with vanilla milkshake.
* inotify has an event that says "the filesystem that the item you were
watching is on was unmounted" (this is particularly cool).
* inotify can watch directories or files.
* The "i" in inotify does not stand for "suck" but for "inode" -- the logical
choice since inotify is inode-based.