From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stef Bon Subject: Re: request: interface notify between VFS and network fs and/or fuse. Date: Wed, 16 Mar 2011 17:01:15 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE To: linux-fsdevel@vger.kernel.org Return-path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:35672 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750884Ab1CPQBQ convert rfc822-to-8bit (ORCPT ); Wed, 16 Mar 2011 12:01:16 -0400 Received: by iwn34 with SMTP id 34so1807566iwn.19 for ; Wed, 16 Mar 2011 09:01:15 -0700 (PDT) In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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-w= orkspace) 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 : > 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 =C2=A0of 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" (an= d > 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 incas= e > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html