Brad Boyer wrote: > On Sun, Jun 06, 2010 at 12:55:35PM +0200, Stef Bon wrote: > > 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. > > Each inode structure in the kernel has a list of outstanding inotify > watch requests, each of which is an inotify_watch structure. Each > inode structure also has a bitmask of any event types in use by an > active watch (this is i_fsnotify_mask in struct inode). Currently > the driver isn't told in any way when these things change. The > driver also isn't given the opportunity to tell the user that > some event types may not actually work properly. If the driver was > notified when the event mask changed, it could send a request to > the server (in the case of CIFS, at least) to start sending > messages for events of those types. Those messages would then need > to be converted and passed to the fsnotify layer in some way. There > are some functions for that part, but they don't really seem to be > designed for this type of use. > > > I know that. > > Futher I know that for the cifs client there are some initiatives to > > make inotify work. > > I knew it had been discussed at one point, but I don't follow the cifs > mailing list. I was trying the other side, using samba with a clustered > file system to export data to Windows clients. > > > So to get bask to the mount --bind issue. Because the inodes are just > > mirrored a inotify request is just handled the same? > > When you create a bind mount, the same inode structures are used both > for the orginal mount and the bind mount. This means that no matter > which path you use for lookup, the kernel finds the same inode. But note that the final component of the path used for access *is* returned to directory watches, such as when monitoring a directory for files opened in it. In that case, I haven't tested but I suspect, if the access is through a bind mount for the final path component, the fs's dentry name is returned to userspace, not the name which was actually used by userspace to do the access. This shouldn't matter if you think of inotify as tracking changes to the filesystem itself. It only goes wrong if you think of inotify as tracking what userspace sees :-) -- Jamie -- 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
