I would like to add to this that for me inotify signals (add/remove watch) are very usefull when building a automounting facility for my fuse fs. I'm planning to create a automount facility only for my fuse fs (fuse-workspace) and it should also react on the fact a inotify watch is set or removed on a inode (part of the automounted resource). Stef 2011/3/16 Stef Bon <stefbon@xxxxxxxxx>: > Hi, > > I'm working on a construction to provide the user a GoboLinux > environment when she or he logs in. > It based upon several techniques, most important is a FUSE fs, > pamchroot, autofs, ConsoleKit, udev, > nbtscan/nmblookup/smbclient and cifs. > > The root looks like: > > /Computer > /Home > /Internet Services > /Mounts > /Network > /Shared > /System > > Well this looks totally different from the standard directories like > /bin, /etc, /sbin ..... They are present but hidden > (done by the fuse fs). > > Now a big showstopper is the lack of integration Âof notify and the > FUSE fs. Notify (well at least inotify) > works when the change is done "on" the fs. For example, when a fuse > overlay fs is mounted at : > > /mnt/examplefs > > and when I do something on that fs: > > cd /mnt/examplefs > touch testfile > > the change is seen by the VFS, and any client, which has set a watch > here, is notified. > This happens completly in VFS, the fuse fs does not do anything here. > > Now I would like to have that the mounted fs is getting some sort of > signal when a client sets a watch to an inode > (on that fs of course). > > It upto the implementation of the fs to decide what to to with the > watch(1). With a simple overlay fs , or a network fs, > it should on hist turn set a watch(2) on the backend, and push every > event from that watch to the original watch(1). > It's up to the fs (with fuse fs's you can do anything, so also > manipulate the evets to pass through or to block here) > how to deal with the watch request. > > > So for example: > > the fusexmp is having the root as backend, just like a bind mount. > > Now user a has mounted it at: > > /home/a/mount > > > another user b has done the same, he has done this at: > > /home/b/mount > > > Now user a set's a watch at: > > > /home/a/mount/tmp > > > and user b creates a file here: > > touch /home/b/mount/tmp/testfile > > Now user a does not see any change. The VFS does not "understand" (and > cannot in anyway) that > > the locations /home/a/mount/tmp and /home/b/mount/tmp are related, > well in fact the same. > > The only way to deal with this situation is to make the fs (in this > case a fuse fs) aware there has been set a watch with a certain mask > on a inode, and there is an interface the fs can send events to incase > somehing happens on the backend. In this example it's required that > the fuse fs itself set's a watch on the underlying fs ( /tmp) and > export any event back . > > Is this possible?? > > 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
