2010/6/7 Brad Boyer <flar@xxxxxxxxxxxxx>: > 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?? Sounds like a lot. I thought only the inodes when asked. >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. This is the same push versus pull dilemma. Changes in the fs when dealing with a network fs or a fuse fs has to be pushed to the local inotify by the remote server (in case of network fs) or by the fuse fs somehowe because the local inotify subsystem cannot do that. My fs is an fuse overlay fs, and the notify subsystem cannot detect/"understand" in any way that changes in the underlying fs are related to changes in my fuse fs. So my fs needs some structure to map inotify watch requests to watch requests at the underlying fs. These watches on the underlying fs need to be monitored (with epoll for example) and when there is activity (=changes) these should be forwarded to the related watches on the fuse fs. Not one to one, because my fs makes changes the behaviour of the underlying fs in some aspects. (otherwise I would simply use a bind mount....). > > 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. Ok I understand. Thanks a lot, Stef -- 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
