Re: Question about inotify and bind mount.

[Stef Bon <stefbon@gmail.com>]

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