On Mon, Jun 07, 2010 at 11:23:54AM +0200, Stef Bon wrote: > 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. Well, each inode has a list which is empty for inodes that aren't being watched. When you add a watch, the corresponding inode has an entry added to its watch list. > >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....). Well, first the kernel would have to have a way to tell the fuse driver what to watch. Then the fuse driver would need a way to notify the user level component what to watch (this would be a protocol change). Only then could your fs have a way to be asked for events and pass them back up into the kernel. It really wouldn't be practical to say what you might need to do until the kernel and fuse support such a thing. It's quite possible that fuse could make it relatively easy for the individual fs developer using fuse. > > > > 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, You're welcome. I'm glad I could help. 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
