Commit | Line | Data |
---|---|---|
de389cf0 MCC |
1 | .. SPDX-License-Identifier: GPL-2.0 |
2 | ||
3 | =============================================================== | |
4 | Inotify - A Powerful yet Simple File Change Notification System | |
5 | =============================================================== | |
0eeca283 RL |
6 | |
7 | ||
8 | ||
9 | Document started 15 Mar 2005 by Robert Love <rml@novell.com> | |
de389cf0 | 10 | |
a5b2f95d | 11 | Document updated 4 Jan 2015 by Zhang Zhen <zhenzhang.zhang@huawei.com> |
de389cf0 MCC |
12 | |
13 | - Deleted obsoleted interface, just refer to manpages for user interface. | |
0eeca283 | 14 | |
a5b2f95d | 15 | (i) Rationale |
0eeca283 | 16 | |
de389cf0 MCC |
17 | Q: |
18 | What is the design decision behind not tying the watch to the open fd of | |
0eeca283 RL |
19 | the watched object? |
20 | ||
de389cf0 MCC |
21 | A: |
22 | Watches are associated with an open inotify device, not an open file. | |
0eeca283 RL |
23 | This solves the primary problem with dnotify: keeping the file open pins |
24 | the file and thus, worse, pins the mount. Dnotify is therefore infeasible | |
25 | for use on a desktop system with removable media as the media cannot be | |
6f97933d | 26 | unmounted. Watching a file should not require that it be open. |
0eeca283 | 27 | |
de389cf0 MCC |
28 | Q: |
29 | What is the design decision behind using an-fd-per-instance as opposed to | |
0eeca283 RL |
30 | an fd-per-watch? |
31 | ||
de389cf0 MCC |
32 | A: |
33 | An fd-per-watch quickly consumes more file descriptors than are allowed, | |
0eeca283 RL |
34 | more fd's than are feasible to manage, and more fd's than are optimally |
35 | select()-able. Yes, root can bump the per-process fd limit and yes, users | |
36 | can use epoll, but requiring both is a silly and extraneous requirement. | |
37 | A watch consumes less memory than an open file, separating the number | |
38 | spaces is thus sensible. The current design is what user-space developers | |
6f97933d RL |
39 | want: Users initialize inotify, once, and add n watches, requiring but one |
40 | fd and no twiddling with fd limits. Initializing an inotify instance two | |
de389cf0 MCC |
41 | thousand times is silly. If we can implement user-space's preferences |
42 | cleanly--and we can, the idr layer makes stuff like this trivial--then we | |
0eeca283 RL |
43 | should. |
44 | ||
45 | There are other good arguments. With a single fd, there is a single | |
46 | item to block on, which is mapped to a single queue of events. The single | |
47 | fd returns all watch events and also any potential out-of-band data. If | |
48 | every fd was a separate watch, | |
49 | ||
50 | - There would be no way to get event ordering. Events on file foo and | |
51 | file bar would pop poll() on both fd's, but there would be no way to tell | |
52 | which happened first. A single queue trivially gives you ordering. Such | |
53 | ordering is crucial to existing applications such as Beagle. Imagine | |
54 | "mv a b ; mv b a" events without ordering. | |
55 | ||
56 | - We'd have to maintain n fd's and n internal queues with state, | |
57 | versus just one. It is a lot messier in the kernel. A single, linear | |
58 | queue is the data structure that makes sense. | |
59 | ||
60 | - User-space developers prefer the current API. The Beagle guys, for | |
61 | example, love it. Trust me, I asked. It is not a surprise: Who'd want | |
62 | to manage and block on 1000 fd's via select? | |
63 | ||
0eeca283 RL |
64 | - No way to get out of band data. |
65 | ||
66 | - 1024 is still too low. ;-) | |
67 | ||
68 | When you talk about designing a file change notification system that | |
69 | scales to 1000s of directories, juggling 1000s of fd's just does not seem | |
70 | the right interface. It is too heavy. | |
71 | ||
6f97933d RL |
72 | Additionally, it _is_ possible to more than one instance and |
73 | juggle more than one queue and thus more than one associated fd. There | |
74 | need not be a one-fd-per-process mapping; it is one-fd-per-queue and a | |
75 | process can easily want more than one queue. | |
76 | ||
de389cf0 MCC |
77 | Q: |
78 | Why the system call approach? | |
0eeca283 | 79 | |
de389cf0 MCC |
80 | A: |
81 | The poor user-space interface is the second biggest problem with dnotify. | |
0eeca283 RL |
82 | Signals are a terrible, terrible interface for file notification. Or for |
83 | anything, for that matter. The ideal solution, from all perspectives, is a | |
84 | file descriptor-based one that allows basic file I/O and poll/select. | |
85 | Obtaining the fd and managing the watches could have been done either via a | |
86 | device file or a family of new system calls. We decided to implement a | |
0edce197 | 87 | family of system calls because that is the preferred approach for new kernel |
6f97933d RL |
88 | interfaces. The only real difference was whether we wanted to use open(2) |
89 | and ioctl(2) or a couple of new system calls. System calls beat ioctls. | |
0eeca283 | 90 |