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. 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
