Index of /archives/linux/kernel.org/kernel/people/rml/inotify

 Name                                          Last modified      Size  Description
 Parent Directory                                                   -   
 MERGED                                        2005-07-14 00:03   38   
 README                                        2004-09-23 02:29  2.1K  
 glib/                                         2013-08-09 04:16    -   
 headers/                                      2013-01-26 00:42    -   
 man-pages/                                    2013-08-09 04:16    -   
 sha256sums.asc                                2023-04-26 06:12  1.0K  
 utils/                                        2013-08-09 04:16    -   
 v2.6/                                         2011-12-09 05:19    -   

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.