Re: [patch] inotify 0.22
From: Dale Blount
Date: Mon Apr 04 2005 - 16:02:25 EST
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/