Question about inotify and bind mount.

Question about inotify and bind mount.

[Stef Bon]

Hello,

I'm developing a fuse filesystem, which aim is to provide a workspace
to the user to access
all kinds of resources, like local devices (USB, CD) and remote like
SMB shares, FTP and SSH (and Netware..)

This construction is based upon a fusemodule and the automounter.

I'm running against the boundaries of what is possible right now.
I'm trying to make inotify possible with fuse, which is very hard.

The goal is to create a complete chrooted environment for the user,
where the system directories are hidden for the user (aka GoboLInux),
but are still there.

My fs is a lot like a mount --bind.

Now I would like to know how a mount --bind works, especially in respect to
the inotify sub system.

When I create the following directories:

mkdir original
mkdir mount.bind.original

somewhere in my homedirectorie
and do as root:

mount --bind original mount.bind.original

and go to the mount.bind.original with a inotify aware client like Dolphin,

and create a file in original like:

touch original/test123

it will also appear in mount.bind.original (per definition) but more important
Dolphin is also direct aware of this change.

So inotify works with bind mounts.
Can someone explain what happens here exactly.
I'm just trying to understand what's happing, I want to know as much
as possible how inotify works.

Thanks in advance,

Stef Bon

Re: Question about inotify and bind mount.

[Brad Boyer]

On Tue, Jun 01, 2010 at 11:49:41AM +0200, Stef Bon wrote:
> So inotify works with bind mounts.
> Can someone explain what happens here exactly.
> I'm just trying to understand what's happing, I want to know as much
> as possible how inotify works.

This is because inotify is directly bound to the inode, not to a
path. Any time the inode is modified through any path, the inotify
client can still get an event.

The basic issue with inotify support in fuse (or in network/cluster
fs drivers) is that the driver is not told when events are desired
on a particular inode. This means that events that appear to be
remote in some sense are very difficult to request. I looked at
this for supporting SMB client directory notifications (for which
samba uses inotify) while exporting a non-local FS. My thought was
that what is required is a way for the fsnotify layer to notify the
FS driver when the event mask changes on an inode (requires a new
inode operation) as well as a clean way for the FS driver to
send arbitrary events which came from the remote end. I didn't
need it bad enough to take the time to write any code yet.

	Brad Boyer
	flar@allandria.com

Re: Question about inotify and bind mount.

[Stef Bon]

Yes I know what you mean, I hope...
You mean there is a inotify structure necessary to handle inotify
requests, and for the driver (a FUSE fs or cifs for SMB to name some)
to act on this request.

I know that.
Futher I know that for the cifs client there are some initiatives to
make inotify work.

So to get bask to the mount --bind issue. Because the inodes are just
mirrored a inotify request is just handled the same?

Stef



2010/6/6 Brad Boyer <flar@allandria.com>:
> On Tue, Jun 01, 2010 at 11:49:41AM +0200, Stef Bon wrote:
>> So inotify works with bind mounts.
>> Can someone explain what happens here exactly.
>> I'm just trying to understand what's happing, I want to know as much
>> as possible how inotify works.
>
> This is because inotify is directly bound to the inode, not to a
> path. Any time the inode is modified through any path, the inotify
> client can still get an event.
>
> The basic issue with inotify support in fuse (or in network/cluster
> fs drivers) is that the driver is not told when events are desired
> on a particular inode. This means that events that appear to be
> remote in some sense are very difficult to request. I looked at
> this for supporting SMB client directory notifications (for which
> samba uses inotify) while exporting a non-local FS. My thought was
> that what is required is a way for the fsnotify layer to notify the
> FS driver when the event mask changes on an inode (requires a new
> inode operation) as well as a clean way for the FS driver to
> send arbitrary events which came from the remote end. I didn't
> need it bad enough to take the time to write any code yet.
>
>        Brad Boyer
>        flar@allandria.com
>
>
--
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: Question about inotify and bind mount.

[Brad Boyer]

On Sun, Jun 06, 2010 at 12:55:35PM +0200, Stef Bon wrote:
> Yes I know what you mean, I hope...
> You mean there is a inotify structure necessary to handle inotify
> requests, and for the driver (a FUSE fs or cifs for SMB to name some)
> to act on this request.

Each inode structure in the kernel has a list of outstanding inotify
watch requests, each of which is an inotify_watch structure. Each
inode structure also has a bitmask of any event types in use by an
active watch (this is i_fsnotify_mask in struct inode). Currently
the driver isn't told in any way when these things change. The
driver also isn't given the opportunity to tell the user that
some event types may not actually work properly. If the driver was
notified when the event mask changed, it could send a request to
the server (in the case of CIFS, at least) to start sending
messages for events of those types. Those messages would then need
to be converted and passed to the fsnotify layer in some way. There
are some functions for that part, but they don't really seem to be
designed for this type of use.

> I know that.
> Futher I know that for the cifs client there are some initiatives to
> make inotify work.

I knew it had been discussed at one point, but I don't follow the cifs
mailing list. I was trying the other side, using samba with a clustered
file system to export data to Windows clients.

> So to get bask to the mount --bind issue. Because the inodes are just
> mirrored a inotify request is just handled the same?

When you create a bind mount, the same inode structures are used both
for the orginal mount and the bind mount. This means that no matter
which path you use for lookup, the kernel finds the same inode.

	Brad Boyer
	flar@allandria.com

Re: Question about inotify and bind mount.

[Jamie Lokier]

Brad Boyer wrote:
> On Sun, Jun 06, 2010 at 12:55:35PM +0200, Stef Bon wrote:
> > Yes I know what you mean, I hope...
> > You mean there is a inotify structure necessary to handle inotify
> > requests, and for the driver (a FUSE fs or cifs for SMB to name some)
> > to act on this request.
> 
> Each inode structure in the kernel has a list of outstanding inotify
> watch requests, each of which is an inotify_watch structure. Each
> inode structure also has a bitmask of any event types in use by an
> active watch (this is i_fsnotify_mask in struct inode). Currently
> the driver isn't told in any way when these things change. The
> driver also isn't given the opportunity to tell the user that
> some event types may not actually work properly. If the driver was
> notified when the event mask changed, it could send a request to
> the server (in the case of CIFS, at least) to start sending
> messages for events of those types. Those messages would then need
> to be converted and passed to the fsnotify layer in some way. There
> are some functions for that part, but they don't really seem to be
> designed for this type of use.
> 
> > I know that.
> > Futher I know that for the cifs client there are some initiatives to
> > make inotify work.
> 
> I knew it had been discussed at one point, but I don't follow the cifs
> mailing list. I was trying the other side, using samba with a clustered
> file system to export data to Windows clients.
> 
> > So to get bask to the mount --bind issue. Because the inodes are just
> > mirrored a inotify request is just handled the same?
> 
> When you create a bind mount, the same inode structures are used both
> for the orginal mount and the bind mount. This means that no matter
> which path you use for lookup, the kernel finds the same inode.

But note that the final component of the path used for access *is*
returned to directory watches, such as when monitoring a directory for
files opened in it.

In that case, I haven't tested but I suspect, if the access is through
a bind mount for the final path component, the fs's dentry name is
returned to userspace, not the name which was actually used by
userspace to do the access.

This shouldn't matter if you think of inotify as tracking changes to
the filesystem itself.  It only goes wrong if you think of inotify as
tracking what userspace sees :-)

-- Jamie

Re: Question about inotify and bind mount.

[Stef Bon]

2010/6/7 Brad Boyer <flar@allandria.com>:
> On Sun, Jun 06, 2010 at 12:55:35PM +0200, Stef Bon wrote:
>> Yes I know what you mean, I hope...
>> You mean there is a inotify structure necessary to handle inotify
>> requests, and for the driver (a FUSE fs or cifs for SMB to name some)
>> to act on this request.
>
> Each inode structure in the kernel has a list of outstanding inotify
> watch requests, each of which is an inotify_watch structure.

Each inode?? Sounds like a lot.
I thought only the inodes when asked.

>Each
> inode structure also has a bitmask of any event types in use by an
> active watch (this is i_fsnotify_mask in struct inode). Currently
> the driver isn't told in any way when these things change. The
> driver also isn't given the opportunity to tell the user that
> some event types may not actually work properly. If the driver was
> notified when the event mask changed, it could send a request to
> the server (in the case of CIFS, at least) to start sending
> messages for events of those types. Those messages would then need
> to be converted and passed to the fsnotify layer in some way. There
> are some functions for that part, but they don't really seem to be
> designed for this type of use.

This is the same push versus pull dilemma. Changes in the fs when
dealing with a network fs or a fuse fs
has to be pushed to the local inotify by the remote server (in case of
network fs) or by the fuse fs somehowe
because the local inotify subsystem cannot do that.

My fs is an fuse overlay fs, and the notify subsystem cannot
detect/"understand" in any way that changes in the underlying fs are
related to changes in my fuse fs.

So my fs needs some structure to map inotify watch requests to watch
requests at the underlying fs.
These watches on the underlying fs need to be monitored (with epoll
for example) and when there is activity (=changes) these should be
forwarded to the related watches on the fuse fs.
Not one to one, because my fs makes changes the behaviour of the
underlying fs in some aspects. (otherwise I would simply use a bind
mount....).

>
> When you create a bind mount, the same inode structures are used both
> for the orginal mount and the bind mount. This means that no matter
> which path you use for lookup, the kernel finds the same inode.

Ok I understand.

Thanks a lot,

Stef

Re: Question about inotify and bind mount.

[Brad Boyer]

On Mon, Jun 07, 2010 at 11:23:54AM +0200, Stef Bon wrote:
> 2010/6/7 Brad Boyer <flar@allandria.com>:
> > On Sun, Jun 06, 2010 at 12:55:35PM +0200, Stef Bon wrote:
> >> Yes I know what you mean, I hope...
> >> You mean there is a inotify structure necessary to handle inotify
> >> requests, and for the driver (a FUSE fs or cifs for SMB to name some)
> >> to act on this request.
> >
> > Each inode structure in the kernel has a list of outstanding inotify
> > watch requests, each of which is an inotify_watch structure.
> 
> Each inode?? Sounds like a lot.
> I thought only the inodes when asked.

Well, each inode has a list which is empty for inodes that aren't being
watched. When you add a watch, the corresponding inode has an entry
added to its watch list.

> >Each
> > inode structure also has a bitmask of any event types in use by an
> > active watch (this is i_fsnotify_mask in struct inode). Currently
> > the driver isn't told in any way when these things change. The
> > driver also isn't given the opportunity to tell the user that
> > some event types may not actually work properly. If the driver was
> > notified when the event mask changed, it could send a request to
> > the server (in the case of CIFS, at least) to start sending
> > messages for events of those types. Those messages would then need
> > to be converted and passed to the fsnotify layer in some way. There
> > are some functions for that part, but they don't really seem to be
> > designed for this type of use.
> 
> This is the same push versus pull dilemma. Changes in the fs when
> dealing with a network fs or a fuse fs
> has to be pushed to the local inotify by the remote server (in case of
> network fs) or by the fuse fs somehowe
> because the local inotify subsystem cannot do that.
> 
> My fs is an fuse overlay fs, and the notify subsystem cannot
> detect/"understand" in any way that changes in the underlying fs are
> related to changes in my fuse fs.
> 
> So my fs needs some structure to map inotify watch requests to watch
> requests at the underlying fs.
> These watches on the underlying fs need to be monitored (with epoll
> for example) and when there is activity (=changes) these should be
> forwarded to the related watches on the fuse fs.
> Not one to one, because my fs makes changes the behaviour of the
> underlying fs in some aspects. (otherwise I would simply use a bind
> mount....).

Well, first the kernel would have to have a way to tell the fuse driver
what to watch. Then the fuse driver would need a way to notify the
user level component what to watch (this would be a protocol change).
Only then could your fs have a way to be asked for events and pass
them back up into the kernel. It really wouldn't be practical to
say what you might need to do until the kernel and fuse support such
a thing. It's quite possible that fuse could make it relatively easy
for the individual fs developer using fuse.

> >
> > When you create a bind mount, the same inode structures are used both
> > for the orginal mount and the bind mount. This means that no matter
> > which path you use for lookup, the kernel finds the same inode.
> 
> Ok I understand.
> 
> Thanks a lot,

You're welcome. I'm glad I could help.

	Brad Boyer
	flar@allandria.com

Re: Question about inotify and bind mount.

[Al Viro]

On Sun, Jun 06, 2010 at 12:55:35PM +0200, Stef Bon wrote:

> So to get bask to the mount --bind issue. Because the inodes are just
> mirrored a inotify request is just handled the same?

They are not mirrored.  They (and dentries and superblock) are literally
the same.  mount --bind results in a new vfsmount that does (as any vfsmount)
refer to a subtree of some fs.  In this case - preexisting subtree.

Mount tree consists of vfsmounts; there's nothing that would prohibit
several vfsmounts refering to the subtrees of the same dentry tree/same
(sub)tree/etc.

Al, carefully not saying what he really thinks of inotify; completely unfit
for repeating in public...