Re: request: interface notify between VFS and network fs and/or fuse.

[Stef Bon <stefbon@gmail.com>]

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@gmail.com>:
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html