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

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

[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  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

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

[Stef Bon]

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