Inotify: Difference between revisions
No edit summary Tags: Reverted Mobile edit Mobile web edit |
Hi Buddy Tags: Reverted categories removed Mobile edit Mobile web edit |
||
| Line 32: | Line 32: | ||
==References== |
==References== |
||
{{Reflist}} |
{{Reflist}} |
||
== External links == |
|||
* [http://www.linuxjournal.com/article/8478 Kernel Korner ]{{snd}} an introduction to inotify by Robert Love (2005) |
|||
* [https://lwn.net/Articles/104343/ LWN Article on Inotify]{{snd}} watching filesystem events with inotify (partly out of date) |
|||
* [http://www.ibm.com/developerworks/linux/library/l-ubuntu-inotify/index.html?ca=drs- IBM Article]{{snd}} monitoring Linux filesystem events with inotify (6 September 2008). |
|||
* [https://lwn.net/Articles/604686/ Filesystem notification, part 1: An overview of dnotify and inotify]{{snd}} an LWN.net article by Michael Kerrisk (2014) |
|||
{{Linux}} |
|||
{{Linux kernel}} |
|||
[[Category:Linux kernel features]] |
|||
Revision as of 03:04, 23 March 2021
D
Limitations
Limitations imposed by inotify include the following:
- Inotify does not support recursively watching directories, meaning that a separate inotify watch must be created for every subdirectory.[1]
- Inotify does report some but not all events in sysfs and procfs.
- Notification via inotify requires the kernel to be aware of all relevant filesystem events, which is not always possible for networked filesystems such as NFS where changes made by one client are not immediately broadcast to other clients.
- Rename events are not handled directly; i.e., inotify issues two separate events that must be examined and matched in a context of potential race conditions.
History
- July 2004: the first release announcement[2]
- August 29, 2005: Linux kernel version 2.6.13 released, containing merged inotify code[3]
- March 2006: GNU C Library (glibc) version 2.4 released, bringing initial inotify support[4]
- September 2006: Glibc version 2.5 released, bringing complete inotify support[4]
Advantages over dnotify
There are a number of advantages when using inotify when compared to the older dnotify API that it replaced.[5][6][7] With dnotify, a program had to use one file descriptor for each directory that it was monitoring. This can become a bottleneck since the limit of file descriptors per process could be reached. Later, fanotify was created to overcome this issue. The use of file descriptors along with dnotify also proved to be a problem when using removable media. Devices could not be unmounted since file descriptors kept the resource busy.
Another drawback of dnotify is the level of granularity, since programmers can only monitor changes at the directory level. To access detailed information about the environmental changes that occur when a notification message is sent, a stat structure must be used; this is considered a necessary evil in that a cache of stat structures has to be maintained, for every new stat structure generated a comparison is run against the cached one.
The inotify API uses fewer file descriptors, allowing programmers to use the established select and poll interface, rather than the signal notification system used by dnotify. This also makes integration with existing select- or poll-based libraries (like GLib) easier.
See also
- File Alteration Monitor (SGI)
- Gamin (Linux, FreeBSD)
- DMAPI
- kqueue (FreeBSD)
- FSEvents (macOS)
References
- ^ Robert Love, Linux system programming. O'Reilly, p. 236
- ^ "fa.linux.kernel post [RFC][PATCH] inotify 0.8". 2004-07-29. Retrieved 2013-08-19.
- ^ Cite error: The named reference
kernelnewbieswas invoked but never defined (see the help page). - ^ a b Cite error: The named reference
man-pagewas invoked but never defined (see the help page). - ^ Michael Kerrisk (14 July 2014). "Filesystem notification, part 2: A deeper investigation of inotify". LWN.net.
- ^ Why inotify? Archived 2010-01-16 at the Wayback Machine
- ^ inotify README file