Again:request for integration inotify in FUSE and fs like CIFS.

Again:request for integration inotify in FUSE and fs like CIFS.

[Stef Bon]

Hi,

some days ago I posted this request. I had no reaction so far, so I
decided to post it again here. Maybe not the best place, if so let me
know.

I'm working on a construction using where a FUSE fs plays an important
role, and it's basically an overlay fs. See:

http://linux.bononline.nl/wiki/index.php/Mount.md5key

and for a screenshot:

http://linux.bononline.nl/wiki/index.php/Introduction_and_motivation#Preview_of_what_my_construction_offers

Now I would like to ask for an interface between the Inotfy subsystem
in VFS and the mounted fs. For example:

the fusexmp FUSE fs takes as backend the root /, so when mounting you
see a mirror of the root at the mountpoint.

No user a mounts it like:

mkdir ~/mount
fusexmp /home/a/mount

When user a (or any other user ) has an app which has set a watch at
the directory /home/a/mount/tmp, watching for changes
here, it will see a change if user a does:

cd ~/mount/tmp
touch testfile


Now when the same user a does:

cd /tmp
rm testfile

this will not be notified by the watch set at /home/a/mount/tmp

This logical: the VFS does not and cannot know the directories
/home/a/mount/tmp and /tmp
are related, and it should not. What my suggestion is to add some
communication between
the VFS and the driver (in this case FUSE) about inotify watches being
set and removed, and additional
tha ability for the driver to notify VFS when something has changed.

So for the example of above it goes like:

the FUSE fs gets a signal there is a watch set at /home/a/mount/tmp
(=tmp under the mountpoint). The fuse fs sets a simular
inotify watch on the backend, in this case /tmp, and will listen for
changes on the inode. When it recieves
some data(inotify events), it will push them forward to the inotify
watch on /home/a/mount/tmp. This is upto the developer
of the FUSE fs to implement this, but required to make this work is:

a. when there is a notify watch set on a mounted FUSE fs, the VFS
should send the FUSE fs a signal a watch (with a mask) is set on a
particular inode. (and also when it's removed)

b. the VFS should be able to listen to notify events coming from the FUSE fs.

Actually the VFS is signalling to the FUSE fs that it wants to have an
inode to be up to date, and to be informed when changes occur.

This example is about FUSE, but it also counts for a fs like cifs.
There the backend is a SMB share, and the SMB server has to support
inotify
to make this work.

I hope you get the picture,

Stef Bon
Voorburg
the Netherlands

Re: Again:request for integration inotify in FUSE and fs like CIFS.

[Al Viro]

On Sat, Mar 19, 2011 at 09:56:17AM +0100, Stef Bon wrote:

> changes on the inode. When it recieves
> some data(inotify events), it will push them forward to the inotify
> watch on /home/a/mount/tmp. This is upto the developer
> of the FUSE fs to implement this, but required to make this work is:
> 
> a. when there is a notify watch set on a mounted FUSE fs, the VFS
> should send the FUSE fs a signal a watch (with a mask) is set on a
> particular inode. (and also when it's removed)
> 
> b. the VFS should be able to listen to notify events coming from the FUSE fs.
> 
> Actually the VFS is signalling to the FUSE fs that it wants to have an
> inode to be up to date, and to be informed when changes occur.
> 
> This example is about FUSE, but it also counts for a fs like cifs.
> There the backend is a SMB share, and the SMB server has to support
> inotify
> to make this work.
> 
> I hope you get the picture,

Why, yes, we do.  You do not.  It is up to you to implement that; it is
up to us to decide whether the result is acceptable for merge...

FWIW, it's a bloody bad idea; inotify is not a generally usable mechanism.
There is no way to make it work for non-local filesystems.  You might be
able to hack up something in FUSE protocol; getting FUSE *servers* to
honour that is something entirely different, seeing that there are tons
of them and these codebases are not in any way under control of kernel
developers - or any single group, for that matter.  Then there is NFS,
where even the protocol side of things is not up to us, not to mention
the server implementations.  The same goes for CIFS/SMB, only there the
odds of affecting the protocol (or one of the common servers - you know,
the native Windows one) are even slimmer.

Program relying on inotify is relying on specific configuration.  Namely,
the areas of the mount tree it's going to watch belonging to one of the
filesystems where inotify works.  Depending on what you are trying to do
there might be saner (and more robust) ways to go - hard to tell without
knowing what are you trying to achieve.

Re: Again:request for integration inotify in FUSE and fs like CIFS.

[Stef Bon]

2011/3/19 Al Viro <viro@zeniv.linux.org.uk>:

>>
>> I hope you get the picture,
>
> Why, yes, we do.  You do not.  It is up to you to implement that; it is
> up to us to decide whether the result is acceptable for merge...
>

OK, I see. I've posted here because there is other location for me to
discuss this issue.
I'm not that experienced in kernel develpment to just come with a
merge right away. I needed some feedback to my idea.

> FWIW, it's a bloody bad idea; inotify is not a generally usable mechanism.
> There is no way to make it work for non-local filesystems.  You might be
> able to hack up something in FUSE protocol; getting FUSE *servers* to
> honour that is something entirely different, seeing that there are tons
> of them and these codebases are not in any way under control of kernel
> developers - or any single group, for that matter.  Then there is NFS,
> where even the protocol side of things is not up to us, not to mention
> the server implementations.  The same goes for CIFS/SMB, only there the
> odds of affecting the protocol (or one of the common servers - you know,
> the native Windows one) are even slimmer.

That's right. I know it will not work always, the backend (or server)
has to support it.
With CIFS/SMB it's even more complicated then with FUSE. And with the
tons of FUSE fs's,
yes a lot of them will not use it, but that normal. A lot of them do
not make use of Extended Attributes while it's possible, FUSE supports
them.

I only want very much inotify supported on the construction I'm working on.

>
> Program relying on inotify is relying on specific configuration.  Namely,
> the areas of the mount tree it's going to watch belonging to one of the
> filesystems where inotify works.  Depending on what you are trying to do
> there might be saner (and more robust) ways to go - hard to tell without
> knowing what are you trying to achieve.

Well I'm building a construction where a FUSE fs play's an important role.
This FUSE fs (fuse-workspace) is basically an overlay fs, so the
backend are filesystems
on the same host, possibly mounted by the automounter.

Well a userspace daemon is possible. There are already sollutions
here, like gamin/fam.

Any suggestions are welcome and appreciated.

Stef Bon
--
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

Re: Again:request for integration inotify in FUSE and fs like CIFS.

[Jeff Layton]

On Sat, 19 Mar 2011 09:49:26 +0000
Al Viro <viro@ZenIV.linux.org.uk> wrote:

> On Sat, Mar 19, 2011 at 09:56:17AM +0100, Stef Bon wrote:
> 
> > changes on the inode. When it recieves
> > some data(inotify events), it will push them forward to the inotify
> > watch on /home/a/mount/tmp. This is upto the developer
> > of the FUSE fs to implement this, but required to make this work is:
> > 
> > a. when there is a notify watch set on a mounted FUSE fs, the VFS
> > should send the FUSE fs a signal a watch (with a mask) is set on a
> > particular inode. (and also when it's removed)
> > 
> > b. the VFS should be able to listen to notify events coming from the FUSE fs.
> > 
> > Actually the VFS is signalling to the FUSE fs that it wants to have an
> > inode to be up to date, and to be informed when changes occur.
> > 
> > This example is about FUSE, but it also counts for a fs like cifs.
> > There the backend is a SMB share, and the SMB server has to support
> > inotify
> > to make this work.
> > 
> > I hope you get the picture,
> 
> Why, yes, we do.  You do not.  It is up to you to implement that; it is
> up to us to decide whether the result is acceptable for merge...
> 
> FWIW, it's a bloody bad idea; inotify is not a generally usable mechanism.
> There is no way to make it work for non-local filesystems.  You might be
> able to hack up something in FUSE protocol; getting FUSE *servers* to
> honour that is something entirely different, seeing that there are tons
> of them and these codebases are not in any way under control of kernel
> developers - or any single group, for that matter.  Then there is NFS,
> where even the protocol side of things is not up to us, not to mention
> the server implementations.  The same goes for CIFS/SMB, only there the
> odds of affecting the protocol (or one of the common servers - you know,
> the native Windows one) are even slimmer.
> 

The CIFS protocol does have some support for async notifications like
this. IIUC, implementation of that in samba was one of the driving
reasons for dnotify. There's even some vestigial code in Linux CIFS
that implements some of the on-the-wire bits.

Actually shoehorning support for that back into the VFS however is a
large, non-trivial project, as Al points out. Steve F. has been talking
about that for a while now (ever since the dir_notify operations were
ripped out), but to my knowledge no one has written any actual code to
do this.

-- 
Jeff Layton <jlayton@redhat.com>

Re: Again:request for integration inotify in FUSE and fs like CIFS.

[Stef Bon]

2011/3/20 Jeff Layton <jlayton@redhat.com>:
> On Sat, 19 Mar 2011 09:49:26 +0000
> Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
>>
>
> The CIFS protocol does have some support for async notifications like
> this. IIUC, implementation of that in samba was one of the driving
> reasons for dnotify. There's even some vestigial code in Linux CIFS
> that implements some of the on-the-wire bits.
>
> Actually shoehorning support for that back into the VFS however is a
> large, non-trivial project, as Al points out. Steve F. has been talking
> about that for a while now (ever since the dir_notify operations were
> ripped out), but to my knowledge no one has written any actual code to
> do this.
>
> --
> Jeff Layton <jlayton@redhat.com>
>

Ok, as I understand you correctly, to implement this in the VFS is complicated.

And doing this in a userspace daemon like gamin is?
Gamin has some methods to do the notifying for clients, using polling,
(i)notify and others which are available.
But with FUSE and cifs it's maybe better to have some communication
between the notify daemon and the mounted filesystem, like messages
coming from the notify daemon to the fs about a notify watch set on a
inode, and messages back about notify events.

With my project, a creating a GoboLinux environement using a FUSE fs
and pamchroot and other techniques, gamin is completly lost and
useless.

Stef