Messages in this thread | | | Subject | Re: [patch] inotify 0.22 | From | Dale Blount <> | Date | Mon, 04 Apr 2005 16:50:55 -0400 |
| |
> inotify is intended to correct the deficiencies of dnotify, particularly > its inability to scale and its terrible user interface: > > * dnotify requires the opening of one fd per each directory > that you intend to watch. This quickly results in too many > open files and pins removable media, preventing unmount. > * 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. > * dnotify's interface to user-space is awful. Signals? > > inotify provides a more usable, simple, powerful solution to file change > notification: > > * inotify's interface is a device node, not SIGIO. You open a > single fd to the device node, which is select()-able. > * inotify has an event that says "the filesystem that the item > you were watching is on was unmounted." > * inotify can watch directories or files. >
Robert and others,
Will inotify watch directories recursively? A quick browse through the source doesn't look like it, but I very well could be wrong. Last I checked, dnotify did not either. I am looking for a way to synchronize files in as-real-as-possible-time when they are modified. The ideal implementation would be a kernel "hook" like d/inotify and a client application that watches changes and copies them to a remote server for redundancy purposes. A scheduled rsync works decently, but has a lag time of 2-3 (or more) hours on certain files on a large filesystem. Will inotify work for this, or does someone else have another recommended solution to the problem?
Thanks,
Dale
- 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/
| |