Yes I know what you mean, I hope... You mean there is a inotify structure necessary to handle inotify requests, and for the driver (a FUSE fs or cifs for SMB to name some) to act on this request. I know that. Futher I know that for the cifs client there are some initiatives to make inotify work. So to get bask to the mount --bind issue. Because the inodes are just mirrored a inotify request is just handled the same? Stef 2010/6/6 Brad Boyer <flar@xxxxxxxxxxxxx>: > On Tue, Jun 01, 2010 at 11:49:41AM +0200, Stef Bon wrote: >> So inotify works with bind mounts. >> Can someone explain what happens here exactly. >> I'm just trying to understand what's happing, I want to know as much >> as possible how inotify works. > > This is because inotify is directly bound to the inode, not to a > path. Any time the inode is modified through any path, the inotify > client can still get an event. > > The basic issue with inotify support in fuse (or in network/cluster > fs drivers) is that the driver is not told when events are desired > on a particular inode. This means that events that appear to be > remote in some sense are very difficult to request. I looked at > this for supporting SMB client directory notifications (for which > samba uses inotify) while exporting a non-local FS. My thought was > that what is required is a way for the fsnotify layer to notify the > FS driver when the event mask changes on an inode (requires a new > inode operation) as well as a clean way for the FS driver to > send arbitrary events which came from the remote end. I didn't > need it bad enough to take the time to write any code yet. > > Brad Boyer > flar@xxxxxxxxxxxxx > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
