Possible to make nfs aware of a inotify watch has been set.

Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

Hi,

as far as I know individual filesystems are not aware an inotify watch
has been set on a
inode managed by that filesystem.

For local only filesystems like ext2/3/4 etcetera this is no problem.
But with network filesystems
like nfs and cifs (and also fuse types) this is not ideal, since
changes made by others (since the backend
is shared with others) are never watched.

I'm working on a filesystem change watcher notifyfs, and puzzling
already for a long time howto enable
the watching of fs events on these filesystems.

I've some idea's:

a. notifyfs is working on the local (A) and the remote host (B), and
is doing it's thing without using the filesystem. When a client
contacts notifyfs to set a watch on a nfs (or cifs) share, notifyfs
detects it a nfs share. It finds out the remote host by analyzing the
mount, and gets the details like remote address and directory. With
nfs that's easy, since the mount is like remotehost:/directory, with
cifs this is a bit more difficult, but doable.
After getting the details, it can forward the watch to the remote host
(B), on which also notifyfs is running, and listning to a tcp port.
This notifyfs process on his turn watches the desired fs object using
the abilities on that host, and sends anything back to the local host
(A).

I've experimented with this, and got it working when using sshfs.

This is very easy to setup, and simple to understand, but some drawbacks:

1. while the filesystems are using credentails or tickets to get
access to a remote resource, this is a bit difficult for notifyfs.
Notifyfs bypasses that. Maybe this leads to permissions/abuse I cannot
see directly.

2. the filesystem still does not know that something has changed (on
B). It should be made aware as fast as possible to make the changes
effective on localhost A. Maybe notifyfs should just trigger that by
doing a lookup on an entry when it has been removed on the remote host
for example.

b. notifyfs forwards the watch to nfs (and cifs) using netlink. Since
nfs and cifs are in kernelspace, and notifyfs is in userspace, netlink
is the way to go to communicate.This is possible, and I've thought
this is the best way to go for a long time, but complicated when
compared to the last method:

c.  make filesystems like nfs and cifs aware a inotify watch has been
set. Untill now the filesystems self are totally not notified a watch
has been set (and of course also changed/removed). This is by design.
For local filesystems it's not required, it will not get any extra,
but nfs and cifs and fuse fs's can use this info to set a watch on the
backend using the methods/api specific to the filesystem. For example
cifs will send a SMB2_CHANGE_NOTIFY to the server, and waiting for
results.

What do you think, is the latest option possible??

Stef Bon

RE: Possible to make nfs aware of a inotify watch has been set.

[Myklebust, Trond]

> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-
> owner@vger.kernel.org] On Behalf Of Stef Bon
> Sent: Thursday, November 29, 2012 4:33 AM
> To: linux-nfs@vger.kernel.org
> Cc: linux-cifs
> Subject: Possible to make nfs aware of a inotify watch has been set.
> 
> Hi,
> 
> as far as I know individual filesystems are not aware an inotify watch has
> been set on a inode managed by that filesystem.
> 
> For local only filesystems like ext2/3/4 etcetera this is no problem.
> But with network filesystems
> like nfs and cifs (and also fuse types) this is not ideal, since changes made by
> others (since the backend is shared with others) are never watched.
> 
> I'm working on a filesystem change watcher notifyfs, and puzzling already for
> a long time howto enable the watching of fs events on these filesystems.
> 
> I've some idea's:
> 
> a. notifyfs is working on the local (A) and the remote host (B), and is doing it's
> thing without using the filesystem. When a client contacts notifyfs to set a
> watch on a nfs (or cifs) share, notifyfs detects it a nfs share. It finds out the
> remote host by analyzing the mount, and gets the details like remote
> address and directory. With nfs that's easy, since the mount is like
> remotehost:/directory, with cifs this is a bit more difficult, but doable.
> After getting the details, it can forward the watch to the remote host (B), on
> which also notifyfs is running, and listning to a tcp port.
> This notifyfs process on his turn watches the desired fs object using the
> abilities on that host, and sends anything back to the local host (A).
> 
> I've experimented with this, and got it working when using sshfs.
> 
> This is very easy to setup, and simple to understand, but some drawbacks:
> 
> 1. while the filesystems are using credentails or tickets to get access to a
> remote resource, this is a bit difficult for notifyfs.
> Notifyfs bypasses that. Maybe this leads to permissions/abuse I cannot see
> directly.

Lack of security is a showstopper. There are good reasons why inotify won't allow you to monitor files for which you don't have access permissions.

> 2. the filesystem still does not know that something has changed (on B). It
> should be made aware as fast as possible to make the changes effective on
> localhost A. Maybe notifyfs should just trigger that by doing a lookup on an
> entry when it has been removed on the remote host for example.
> 
> b. notifyfs forwards the watch to nfs (and cifs) using netlink. Since nfs and
> cifs are in kernelspace, and notifyfs is in userspace, netlink is the way to go to
> communicate.This is possible, and I've thought this is the best way to go for a
> long time, but complicated when compared to the last method:
> 
> c.  make filesystems like nfs and cifs aware a inotify watch has been set. Untill
> now the filesystems self are totally not notified a watch has been set (and of
> course also changed/removed). This is by design.
> For local filesystems it's not required, it will not get any extra, but nfs and cifs
> and fuse fs's can use this info to set a watch on the backend using the
> methods/api specific to the filesystem. For example cifs will send a
> SMB2_CHANGE_NOTIFY to the server, and waiting for results.
> 
> What do you think, is the latest option possible??

So what is the killer app for inotify on NFS/CIFS/FUSE? What programs do you need to run on a NFS/CIFS/FUSE client that use inotify and that wouldn't be better off running on the server instead?

IOW: whose problem are you trying to solve?

Trond

Re: Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
>> -----Original Message-----
>>
>> 1. while the filesystems are using credentails or tickets to get access to a
>> remote resource, this is a bit difficult for notifyfs.
>> Notifyfs bypasses that. Maybe this leads to permissions/abuse I cannot see
>> directly.
>
> Lack of security is a showstopper. There are good reasons why inotify won't allow you to monitor files for which you don't have access permissions.
>

Let me explain, I think you not understand fully.

Notifyfs does not allow users/clients to set a watch if there are no
read permissions (the object and access for the whole path to it), so
there are no security issues there.

What I mean is that any program can contact the remote notifyfs
server, and this remote notifyfs server cannot figure out it's a valid
request from another notifyfs server, or a program faking that.
In the construction I describe it does not check that (yet).

>>
>> What do you think, is the latest option possible??
>
> So what is the killer app for inotify on NFS/CIFS/FUSE? What programs do you need to run on a NFS/CIFS/FUSE client that use inotify and that wouldn't be better off running on the server instead?
>

What do you mean with "better off running on the server instead"?
There are a lot of programs interested in fs changes, like a simple
file manager. I think it's a very nice feature to see changes right
away in the view.
It's not a killer app, but a think the whole user experience is
improving when your system is able to keep a view (like a view in the
file manager) up to date.

> IOW: whose problem are you trying to solve?

I think that enabling fs notify on network filesystems like nfs, cifs
and fuse is a good thing (see above). On systems like Windows and iOS
since long time this works.

You do not agree??

Stef Bon

RE: Possible to make nfs aware of a inotify watch has been set.

[Myklebust, Trond]

> -----Original Message-----
> From: Stef Bon [mailto:stefbon@gmail.com]
> Sent: Thursday, November 29, 2012 9:49 AM
> To: Myklebust, Trond
> Cc: linux-nfs@vger.kernel.org; linux-cifs
> Subject: Re: Possible to make nfs aware of a inotify watch has been set.
> 
> 2012/11/29 Myklebust, Trond <Trond.Myklebust@netapp.com>:
> >> -----Original Message-----
> >>
> >> 1. while the filesystems are using credentails or tickets to get
> >> access to a remote resource, this is a bit difficult for notifyfs.
> >> Notifyfs bypasses that. Maybe this leads to permissions/abuse I
> >> cannot see directly.
> >
> > Lack of security is a showstopper. There are good reasons why inotify won't
> allow you to monitor files for which you don't have access permissions.
> >
> 
> Let me explain, I think you not understand fully.
> 
> Notifyfs does not allow users/clients to set a watch if there are no read
> permissions (the object and access for the whole path to it), so there are no
> security issues there.
> 
> What I mean is that any program can contact the remote notifyfs server, and
> this remote notifyfs server cannot figure out it's a valid request from another
> notifyfs server, or a program faking that.
> In the construction I describe it does not check that (yet).
> 
> >>
> >> What do you think, is the latest option possible??
> >
> > So what is the killer app for inotify on NFS/CIFS/FUSE? What programs do
> you need to run on a NFS/CIFS/FUSE client that use inotify and that wouldn't
> be better off running on the server instead?
> >
> 
> What do you mean with "better off running on the server instead"?
> There are a lot of programs interested in fs changes, like a simple file
> manager. I think it's a very nice feature to see changes right away in the view.
> It's not a killer app, but a think the whole user experience is improving when
> your system is able to keep a view (like a view in the file manager) up to
> date.
> 
> > IOW: whose problem are you trying to solve?
> 
> I think that enabling fs notify on network filesystems like nfs, cifs and fuse is
> a good thing (see above). On systems like Windows and iOS since long time
> this works.
> 
> You do not agree??

No. I like having a reason for adding kernel functionality.

Trond
 

Re: Possible to make nfs aware of a inotify watch has been set.

[simo]

On Thu, 2012-11-29 at 15:49 +0100, Stef Bon wrote:
> 2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
> >> -----Original Message-----
> >>
> >> 1. while the filesystems are using credentails or tickets to get access to a
> >> remote resource, this is a bit difficult for notifyfs.
> >> Notifyfs bypasses that. Maybe this leads to permissions/abuse I cannot see
> >> directly.
> >
> > Lack of security is a showstopper. There are good reasons why inotify won't allow you to monitor files for which you don't have access permissions.
> >
> 
> Let me explain, I think you not understand fully.
> 
> Notifyfs does not allow users/clients to set a watch if there are no
> read permissions (the object and access for the whole path to it), so
> there are no security issues there.
> 
> What I mean is that any program can contact the remote notifyfs
> server, and this remote notifyfs server cannot figure out it's a valid
> request from another notifyfs server, or a program faking that.
> In the construction I describe it does not check that (yet).
> 
> >>
> >> What do you think, is the latest option possible??
> >
> > So what is the killer app for inotify on NFS/CIFS/FUSE? What programs do you need to run on a NFS/CIFS/FUSE client that use inotify and that wouldn't be better off running on the server instead?
> >
> 
> What do you mean with "better off running on the server instead"?
> There are a lot of programs interested in fs changes, like a simple
> file manager. I think it's a very nice feature to see changes right
> away in the view.
> It's not a killer app, but a think the whole user experience is
> improving when your system is able to keep a view (like a view in the
> file manager) up to date.
> 
> > IOW: whose problem are you trying to solve?
> 
> I think that enabling fs notify on network filesystems like nfs, cifs
> and fuse is a good thing (see above). On systems like Windows and iOS
> since long time this works.

CIFS has notification capabilities built in (oplocks), as does NFS
(leases), is this not sufficient ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: Possible to make nfs aware of a inotify watch has been set.

[Myklebust, Trond]

On Thu, 2012-11-29 at 10:22 -0500, simo wrote:
> On Thu, 2012-11-29 at 15:49 +0100, Stef Bon wrote:
> > 2012/11/29 Myklebust, Trond <Trond.Myklebust@netapp.com>:
> > >> -----Original Message-----
> > >>
> > >> 1. while the filesystems are using credentails or tickets to get access to a
> > >> remote resource, this is a bit difficult for notifyfs.
> > >> Notifyfs bypasses that. Maybe this leads to permissions/abuse I cannot see
> > >> directly.
> > >
> > > Lack of security is a showstopper. There are good reasons why inotify won't allow you to monitor files for which you don't have access permissions.
> > >
> > 
> > Let me explain, I think you not understand fully.
> > 
> > Notifyfs does not allow users/clients to set a watch if there are no
> > read permissions (the object and access for the whole path to it), so
> > there are no security issues there.
> > 
> > What I mean is that any program can contact the remote notifyfs
> > server, and this remote notifyfs server cannot figure out it's a valid
> > request from another notifyfs server, or a program faking that.
> > In the construction I describe it does not check that (yet).
> > 
> > >>
> > >> What do you think, is the latest option possible??
> > >
> > > So what is the killer app for inotify on NFS/CIFS/FUSE? What programs do you need to run on a NFS/CIFS/FUSE client that use inotify and that wouldn't be better off running on the server instead?
> > >
> > 
> > What do you mean with "better off running on the server instead"?
> > There are a lot of programs interested in fs changes, like a simple
> > file manager. I think it's a very nice feature to see changes right
> > away in the view.
> > It's not a killer app, but a think the whole user experience is
> > improving when your system is able to keep a view (like a view in the
> > file manager) up to date.
> > 
> > > IOW: whose problem are you trying to solve?
> > 
> > I think that enabling fs notify on network filesystems like nfs, cifs
> > and fuse is a good thing (see above). On systems like Windows and iOS
> > since long time this works.
> 
> CIFS has notification capabilities built in (oplocks), as does NFS
> (leases), is this not sufficient ?

NFSv4.1 actually has directory notifications which duplicate most of the
functionality of dnotify. The question I'm asking is "Why should we do
it?", not "can we do it?".

Answers like "well Windows and iOS do it" aren't helpful unless they
include a description of what Windows and iOS apps use it for that we
can't already do on Linux.
If the only application is beagle, then Linux has this really helpful
utility called "ssh", which allows you to avoid wasting a load of
network bandwidth...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: Possible to make nfs aware of a inotify watch has been set.

[Steve French]

On Thu, Nov 29, 2012 at 9:33 AM, Myklebust, Trond
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 2012-11-29 at 10:22 -0500, simo wrote:
>> On Thu, 2012-11-29 at 15:49 +0100, Stef Bon wrote:
>> > 2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
>> > >> -----Original Message-----
>> > >>
>> > >> 1. while the filesystems are using credentails or tickets to get access to a
>> > >> remote resource, this is a bit difficult for notifyfs.
>> > >> Notifyfs bypasses that. Maybe this leads to permissions/abuse I cannot see
>> > >> directly.
>> > >
>> > > Lack of security is a showstopper. There are good reasons why inotify won't allow you to monitor files for which you don't have access permissions.
>> > >
>> >
>> > Let me explain, I think you not understand fully.
>> >
>> > Notifyfs does not allow users/clients to set a watch if there are no
>> > read permissions (the object and access for the whole path to it), so
>> > there are no security issues there.
>> >
>> > What I mean is that any program can contact the remote notifyfs
>> > server, and this remote notifyfs server cannot figure out it's a valid
>> > request from another notifyfs server, or a program faking that.
>> > In the construction I describe it does not check that (yet).
>> >
>> > >>
>> > >> What do you think, is the latest option possible??
>> > >
>> > > So what is the killer app for inotify on NFS/CIFS/FUSE? What programs do you need to run on a NFS/CIFS/FUSE client that use inotify and that wouldn't be better off running on the server instead?
>> > >
>> >
>> > What do you mean with "better off running on the server instead"?
>> > There are a lot of programs interested in fs changes, like a simple
>> > file manager. I think it's a very nice feature to see changes right
>> > away in the view.
>> > It's not a killer app, but a think the whole user experience is
>> > improving when your system is able to keep a view (like a view in the
>> > file manager) up to date.
>> >
>> > > IOW: whose problem are you trying to solve?
>> >
>> > I think that enabling fs notify on network filesystems like nfs, cifs
>> > and fuse is a good thing (see above). On systems like Windows and iOS
>> > since long time this works.
>>
>> CIFS has notification capabilities built in (oplocks), as does NFS
>> (leases), is this not sufficient ?
>
> NFSv4.1 actually has directory notifications which duplicate most of the
> functionality of dnotify. The question I'm asking is "Why should we do
> it?", not "can we do it?".
>
> Answers like "well Windows and iOS do it" aren't helpful unless they
> include a description of what Windows and iOS apps use it for that we
> can't already do on Linux.
> If the only application is beagle, then Linux has this really helpful
> utility called "ssh", which allows you to avoid wasting a load of
> network bandwidth...

Of course one reason that file managers like directory notifications is that
it avoids wasting a load of network bandwidth - as the alternative to
directory change
notifications is polling the directories for every open window.   Also note that
network file systems where possible should implement similar semantics and
interfaces to the local file systems, and inotify/dnotify are mappable
to network
'file systems (presumably not just cifs/smb2/smb3).   Support for
keeping file manager
views reasonably up to date would be a good enough reason for something like
inotify/dnotify (and it has been used by file managers for over 20
years, even before
Windows and iOS) - and we want to get to the point where home directories
work as well on network mounts as on local storage.

Directory oplocks (in smb3) may be helpful in reducing the number of remote
directory change notifications further.



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
> On Thu, 2012-11-29 at 10:22 -0500, simo wrote:
>> On Thu, 2012-11-29 at 15:49 +0100, Stef Bon wrote:
>> > 2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
>> > >> -----Original Message-----
>> > >>
> NFSv4.1 actually has directory notifications which duplicate most of the
> functionality of dnotify. The question I'm asking is "Why should we do
> it?", not "can we do it?".
>
> Answers like "well Windows and iOS do it" aren't helpful unless they
> include a description of what Windows and iOS apps use it for that we
> can't already do on Linux.
> If the only application is beagle, then Linux has this really helpful
> utility called "ssh", which allows you to avoid wasting a load of
> network bandwidth...

No, sure, you should not do anything because others do it. But on the
other hand, if others do it, why don't you? Better copy a good idea
than be stubborn for ever.

And yes there is no such thing as a killer app, but in my opinion it's
the user experience. It's so much better when your system keeps track
on shared network resources.

But first things first,I will try to make the first option work, which
was the use of a remote notifyfs server. This works of course only
with linux like systems: so not when the remote server is a Windows
server.

I know that SMB (2?) has the ability to send a SMB2_CHANGE_NOTIFY
request. Steve French and I had earlier a conversation about that.

Before trying to make this work with cifs I've tried to make this work
using a FUSE fs with libsmbclient. I did not get it working since the
adding of an fd to the FUSE fs's eventloop was not easy, and required
a rewrite of libsmbclient.
The writing of the FUSE fs was easy, since there are already some examples.

Stef

Re: Possible to make nfs aware of a inotify watch has been set.

[Myklebust, Trond]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4764 bytes --]

On Thu, 2012-11-29 at 10:28 -0600, Steve French wrote:
> On Thu, Nov 29, 2012 at 9:33 AM, Myklebust, Trond
> <Trond.Myklebust@netapp.com> wrote:
> > On Thu, 2012-11-29 at 10:22 -0500, simo wrote:
> >> On Thu, 2012-11-29 at 15:49 +0100, Stef Bon wrote:
> >> > 2012/11/29 Myklebust, Trond <Trond.Myklebust@netapp.com>:
> >> > >> -----Original Message-----
> >> > >>
> >> > >> 1. while the filesystems are using credentails or tickets to get access to a
> >> > >> remote resource, this is a bit difficult for notifyfs.
> >> > >> Notifyfs bypasses that. Maybe this leads to permissions/abuse I cannot see
> >> > >> directly.
> >> > >
> >> > > Lack of security is a showstopper. There are good reasons why inotify won't allow you to monitor files for which you don't have access permissions.
> >> > >
> >> >
> >> > Let me explain, I think you not understand fully.
> >> >
> >> > Notifyfs does not allow users/clients to set a watch if there are no
> >> > read permissions (the object and access for the whole path to it), so
> >> > there are no security issues there.
> >> >
> >> > What I mean is that any program can contact the remote notifyfs
> >> > server, and this remote notifyfs server cannot figure out it's a valid
> >> > request from another notifyfs server, or a program faking that.
> >> > In the construction I describe it does not check that (yet).
> >> >
> >> > >>
> >> > >> What do you think, is the latest option possible??
> >> > >
> >> > > So what is the killer app for inotify on NFS/CIFS/FUSE? What programs do you need to run on a NFS/CIFS/FUSE client that use inotify and that wouldn't be better off running on the server instead?
> >> > >
> >> >
> >> > What do you mean with "better off running on the server instead"?
> >> > There are a lot of programs interested in fs changes, like a simple
> >> > file manager. I think it's a very nice feature to see changes right
> >> > away in the view.
> >> > It's not a killer app, but a think the whole user experience is
> >> > improving when your system is able to keep a view (like a view in the
> >> > file manager) up to date.
> >> >
> >> > > IOW: whose problem are you trying to solve?
> >> >
> >> > I think that enabling fs notify on network filesystems like nfs, cifs
> >> > and fuse is a good thing (see above). On systems like Windows and iOS
> >> > since long time this works.
> >>
> >> CIFS has notification capabilities built in (oplocks), as does NFS
> >> (leases), is this not sufficient ?
> >
> > NFSv4.1 actually has directory notifications which duplicate most of the
> > functionality of dnotify. The question I'm asking is "Why should we do
> > it?", not "can we do it?".
> >
> > Answers like "well Windows and iOS do it" aren't helpful unless they
> > include a description of what Windows and iOS apps use it for that we
> > can't already do on Linux.
> > If the only application is beagle, then Linux has this really helpful
> > utility called "ssh", which allows you to avoid wasting a load of
> > network bandwidth...
> 
> Of course one reason that file managers like directory notifications is that
> it avoids wasting a load of network bandwidth - as the alternative to
> directory change
> notifications is polling the directories for every open window.   Also note that
> network file systems where possible should implement similar semantics and
> interfaces to the local file systems, and inotify/dnotify are mappable
> to network
> 'file systems (presumably not just cifs/smb2/smb3).   Support for
> keeping file manager
> views reasonably up to date would be a good enough reason for something like
> inotify/dnotify (and it has been used by file managers for over 20
> years, even before
> Windows and iOS) - and we want to get to the point where home directories
> work as well on network mounts as on local storage.

gamin and the FAM protocol already fills the file manager/browser gap as
far as I know. Nobody has come knocking on my door from the GNOME or KDE
projects asking for more functionality from the NFS client.

> Directory oplocks (in smb3) may be helpful in reducing the number of remote
> directory change notifications further.

When CITI tried to actually measure the effect of NFSv4.1 directory
delegations on network bandwidth, they found nothing. We're already
being efficient for the case where the directory is not being changed by
anyone other than us.
BTW: inotify already works for that case on both CIFS and NFS.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±û"žØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br	šê+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹\x1e®w¥¢¸?™¨è­Ú&¢)ߢ^[f

Re: Possible to make nfs aware of a inotify watch has been set.

[Myklebust, Trond]

On Thu, 2012-11-29 at 17:39 +0100, Stef Bon wrote:
> 2012/11/29 Myklebust, Trond <Trond.Myklebust@netapp.com>:
> > On Thu, 2012-11-29 at 10:22 -0500, simo wrote:
> >> On Thu, 2012-11-29 at 15:49 +0100, Stef Bon wrote:
> >> > 2012/11/29 Myklebust, Trond <Trond.Myklebust@netapp.com>:
> >> > >> -----Original Message-----
> >> > >>
> > NFSv4.1 actually has directory notifications which duplicate most of the
> > functionality of dnotify. The question I'm asking is "Why should we do
> > it?", not "can we do it?".
> >
> > Answers like "well Windows and iOS do it" aren't helpful unless they
> > include a description of what Windows and iOS apps use it for that we
> > can't already do on Linux.
> > If the only application is beagle, then Linux has this really helpful
> > utility called "ssh", which allows you to avoid wasting a load of
> > network bandwidth...
> 
> No, sure, you should not do anything because others do it. But on the
> other hand, if others do it, why don't you? Better copy a good idea
> than be stubborn for ever.

The idea that "if we build a bridge, they will come to us" is what gave
rise to dnotify, then inotify (nobody came, so let's build a bigger
bridge) and fsnotify (make it a toll bridge). Nobody is using those
interfaces much on local filesystems, so why is adding it to NFS and
CIFS going to be such a game changer?

> And yes there is no such thing as a killer app, but in my opinion it's
> the user experience. It's so much better when your system keeps track
> on shared network resources.

What does it enable us to do that we can't already do? This is precisely
the question that I asked you in the previous email.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: Possible to make nfs aware of a inotify watch has been set.

[simo]

On Thu, 2012-11-29 at 17:11 +0000, Myklebust, Trond wrote:
> The idea that "if we build a bridge, they will come to us" is what
> gave
> rise to dnotify, then inotify (nobody came, so let's build a bigger
> bridge) and fsnotify (make it a toll bridge). Nobody is using those
> interfaces much on local filesystems, so why is adding it to NFS and
> CIFS going to be such a game changer?

Sorry Trond,
but this is simply not true.

inotify is a key feature at least in some packages I know, and makes
some things *a lot* easier.

Of course this are less visible features, that are easy to overlook, but
they are not unused for sure.

(dnotify on the other hand was underused because it was almost useless)

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
> On Thu, 2012-11-29 at 17:39 +0100, Stef Bon wrote:
>> 2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
>> > On Thu, 2012-11-29 at 10:22 -0500, simo wrote:
>> >> On Thu, 2012-11-29 at 15:49 +0100, Stef Bon wrote:
>> >> > 2012/11/29 Myklebust, Trond <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>:
>> >> > >> -----Original Message-----
>> >> > >>

>>
>> No, sure, you should not do anything because others do it. But on the
>> other hand, if others do it, why don't you? Better copy a good idea
>> than be stubborn for ever.
>
> The idea that "if we build a bridge, they will come to us" is what gave
> rise to dnotify, then inotify (nobody came, so let's build a bigger
> bridge) and fsnotify (make it a toll bridge). Nobody is using those
> interfaces much on local filesystems, so why is adding it to NFS and
> CIFS going to be such a game changer?

Well that's a good question. I've been working on this issue for some
time now, and do not find much interest in it. I do not understand!

Although I find this a bit frustating, I still beleive it's a good
feature.  And yes, I believe that what you suggest with building a
bridge (having a good idea) they will come to us.

And I've [posted on qt dev platforms, and they mentioned me that they
need much more fine grained methods, that just "something has
changed". But ok, that has nothing to do with nfs ...


>
>> And yes there is no such thing as a killer app, but in my opinion it's
>> the user experience. It's so much better when your system keeps track
>> on shared network resources.
>
> What does it enable us to do that we can't already do? This is precisely
> the question that I asked you in the previous email.

Huh? Is it possible to monitor directories and other objects for
changes already with network fs's??

By polling? The poor mans fs notify service?

Stef

Re: Possible to make nfs aware of a inotify watch has been set.

[Al Viro]

On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:

> And yes there is no such thing as a killer app, but in my opinion it's
> the user experience.

Ah, yes...  UX - the killer argument.  "Doing that would make qi flow better"
and any objections are waved away, since the person objecting has no idea
how qi behaves (since it doesn't exist, to start with).  Could we please keep
the intellectual level above the Feng Shui scammers^W^W^WUX theorists usual?

Re: Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
> On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:
>
>> And yes there is no such thing as a killer app, but in my opinion it's
>> the user experience.
>
> Ah, yes...  UX - the killer argument.  "Doing that would make qi flow better"
> and any objections are waved away, since the person objecting has no idea
> how qi behaves (since it doesn't exist, to start with).  Could we please keep
> the intellectual level above the Feng Shui scammers^W^W^WUX theorists usual?

Wow. Like I've said, I do not have a killer app, or anything else
which is as obvious like 1+1=2. No, but I give you my opinion. To me,
boldly stated, a system which is able to do fs notify events over
network filesystems is turning from a dump system into an intelligent
one.

With Ubuntu people started Unity, also without a killer app, but just
with an opinion, an impression, an idea. And anyone can dislike or
like it, it's a succes as far as I can see. What the hell is wrong
with suggesting things based upon an idea/impression?

Stef

Re: Possible to make nfs aware of a inotify watch has been set.

[Myklebust, Trond]

On Thu, 2012-11-29 at 15:05 -0500, simo wrote:
> On Thu, 2012-11-29 at 17:11 +0000, Myklebust, Trond wrote:
> > The idea that "if we build a bridge, they will come to us" is what
> > gave
> > rise to dnotify, then inotify (nobody came, so let's build a bigger
> > bridge) and fsnotify (make it a toll bridge). Nobody is using those
> > interfaces much on local filesystems, so why is adding it to NFS and
> > CIFS going to be such a game changer?
> 
> Sorry Trond,
> but this is simply not true.
> 
> inotify is a key feature at least in some packages I know, and makes
> some things *a lot* easier.
> 
> Of course this are less visible features, that are easy to overlook, but
> they are not unused for sure.

So why is it so difficult for anyone in this thread to name these killer
applications that would benefit from NFS+CIFS support? I keep asking,
and all I get is wishy-washy and hand-wavy answers.

Without use cases, there is nothing to discuss on the implementation
front.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: Possible to make nfs aware of a inotify watch has been set.

[Al Viro]

On Thu, Nov 29, 2012 at 09:31:05PM +0100, Stef Bon wrote:
> 2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
> > On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:
> >
> >> And yes there is no such thing as a killer app, but in my opinion it's
> >> the user experience.
> >
> > Ah, yes...  UX - the killer argument.  "Doing that would make qi flow better"
> > and any objections are waved away, since the person objecting has no idea
> > how qi behaves (since it doesn't exist, to start with).  Could we please keep
> > the intellectual level above the Feng Shui scammers^W^W^WUX theorists usual?
> 
> Wow. Like I've said, I do not have a killer app, or anything else
> which is as obvious like 1+1=2. No, but I give you my opinion. To me,
> boldly stated, a system which is able to do fs notify events over
> network filesystems is turning from a dump system into an intelligent
> one.
> 
> With Ubuntu people started Unity, also without a killer app, but just
> with an opinion, an impression, an idea. And anyone can dislike or
> like it, it's a succes as far as I can see. What the hell is wrong
> with suggesting things based upon an idea/impression?

IOW, it was a true positive for "([Uu]ser experience)|UX" as BS predictor.
Nice to know...

Look, you'd been asked to give good reasons for doing some thing; replying with
"it's My Opinion(tm), piss off if that's not enough reason for you" would at
least have been honest.  References to UX, as your last reply has confirmed,
had been basically an obfuscated equivalent of that.

Sorry for being harsh, but I've had it with the GNOME crowd and their ilk
using just such references to handwave away any questions.

There's nothing wrong with having opinions/impressions/etc.  Everyone got
their own, etc.  But "I believe so, period" is not a sufficient answer to
"what makes that a good idea?" and obfuscating it up is even worse.

Re: Possible to make nfs aware of a inotify watch has been set.

[simo]

On Thu, 2012-11-29 at 21:09 +0000, Myklebust, Trond wrote:
> On Thu, 2012-11-29 at 15:05 -0500, simo wrote:
> > On Thu, 2012-11-29 at 17:11 +0000, Myklebust, Trond wrote:
> > > The idea that "if we build a bridge, they will come to us" is what
> > > gave
> > > rise to dnotify, then inotify (nobody came, so let's build a bigger
> > > bridge) and fsnotify (make it a toll bridge). Nobody is using those
> > > interfaces much on local filesystems, so why is adding it to NFS and
> > > CIFS going to be such a game changer?
> > 
> > Sorry Trond,
> > but this is simply not true.
> > 
> > inotify is a key feature at least in some packages I know, and makes
> > some things *a lot* easier.
> > 
> > Of course this are less visible features, that are easy to overlook, but
> > they are not unused for sure.
> 
> So why is it so difficult for anyone in this thread to name these killer
> applications that would benefit from NFS+CIFS support? I keep asking,
> and all I get is wishy-washy and hand-wavy answers.
> 
> Without use cases, there is nothing to discuss on the implementation
> front.

Sorry for the misunderstanding, I wasn't talking about inotify *on
CIFS/NFS*, I do not care about that use case, I'll gladly let Stef pitch
it for himself :)

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Principal Software Engineer at Red Hat, Inc. <simo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
> On Thu, Nov 29, 2012 at 09:31:05PM +0100, Stef Bon wrote:
>> 2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
>> > On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:
>> >

>> With Ubuntu people started Unity, also without a killer app, but just
>> with an opinion, an impression, an idea. And anyone can dislike or
>> like it, it's a succes as far as I can see. What the hell is wrong
>> with suggesting things based upon an idea/impression?
>
> IOW, it was a true positive for "([Uu]ser experience)|UX" as BS predictor.
> Nice to know...
>
> Look, you'd been asked to give good reasons for doing some thing; replying with
> "it's My Opinion(tm), piss off if that's not enough reason for you" would at
> least have been honest.  References to UX, as your last reply has confirmed,
> had been basically an obfuscated equivalent of that.

No no, I do not say "piss off". If that is what my message looked
like, I'm sorry for that. But I do not have any killer app or
something. I cannot convince you otherwise that saying it's my
opinion. I do not have numbers or something like that proving I have a
point. I wish I have. But I do understand you do not agree with me,
and see things different.
>
> Sorry for being harsh, but I've had it with the GNOME crowd and their ilk
> using just such references to handwave away any questions.
>
> There's nothing wrong with having opinions/impressions/etc.  Everyone got
> their own, etc.  But "I believe so, period" is not a sufficient answer to
> "what makes that a good idea?" and obfuscating it up is even worse.

So, no I do not say "I believe so, period" . But I cannot convince you
...and we have different opinions here.. I don't know any method here
of "proving having a point".

Stef

Re: Possible to make nfs aware of a inotify watch has been set.

[Steve French]

On Thu, Nov 29, 2012 at 5:14 PM, Stef Bon <stefbon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
>> On Thu, Nov 29, 2012 at 09:31:05PM +0100, Stef Bon wrote:
>>> 2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
>>> > On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:
>>> >
>
>>> With Ubuntu people started Unity, also without a killer app, but just
>>> with an opinion, an impression, an idea. And anyone can dislike or
>>> like it, it's a succes as far as I can see. What the hell is wrong
>>> with suggesting things based upon an idea/impression?
>>
>> IOW, it was a true positive for "([Uu]ser experience)|UX" as BS predictor.
>> Nice to know...
>>
>> Look, you'd been asked to give good reasons for doing some thing; replying with
>> "it's My Opinion(tm), piss off if that's not enough reason for you" would at
>> least have been honest.  References to UX, as your last reply has confirmed,
>> had been basically an obfuscated equivalent of that.
>
> No no, I do not say "piss off". If that is what my message looked
> like, I'm sorry for that. But I do not have any killer app or
> something. I cannot convince you otherwise that saying it's my
> opinion. I do not have numbers or something like that proving I have a
> point. I wish I have. But I do understand you do not agree with me,
> and see things different.
>>
>> Sorry for being harsh, but I've had it with the GNOME crowd and their ilk
>> using just such references to handwave away any questions.
>>
>> There's nothing wrong with having opinions/impressions/etc.  Everyone got
>> their own, etc.  But "I believe so, period" is not a sufficient answer to
>> "what makes that a good idea?" and obfuscating it up is even worse.
>
> So, no I do not say "I believe so, period" . But I cannot convince you
> ...and we have different opinions here.. I don't know any method here
> of "proving having a point".

One question that hasn't been answered AFAIK is how well the current
Linux directory change notification API maps to the needs of its principal user
(presumably Samba, and kde/gnome file managers), and a loosely
related question of how well the change notification API maps to the
corresponding network file system protocol operations
(TRANSACT_NOTIFY_CHANGE) which is a fairly common operation
sent to Samba, and obviously for the cifs/smb2/smb3 case would limit
what types of events the client can notify the desktop/file manager about.

In particular, the 10 or 15 filter flags, and the (at least) 8 events
(add/remove/modify/rename etc.),
available in tne network protocol AFAIK have not been matched to see if they
match closely to the existing Linux API.

-- 
Thanks,

Steve

Re: Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

2012/11/30 Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> On Thu, Nov 29, 2012 at 5:14 PM, Stef Bon <stefbon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> 2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
>>> On Thu, Nov 29, 2012 at 09:31:05PM +0100, Stef Bon wrote:
>>>> 2012/11/29 Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>:
>>>> > On Thu, Nov 29, 2012 at 05:39:27PM +0100, Stef Bon wrote:
>>>> >
>>
>>>> With Ubuntu people started Unity, also without a killer app, but just
>>>> with an opinion, an impression, an idea. And anyone can dislike or
>>>> like it, it's a succes as far as I can see. What the hell is wrong
>>>> with suggesting things based upon an idea/impression?
>>>
>>> IOW, it was a true positive for "([Uu]ser experience)|UX" as BS predictor.
>>> Nice to know...
>>>
>>> Look, you'd been asked to give good reasons for doing some thing; replying with
>>> "it's My Opinion(tm), piss off if that's not enough reason for you" would at
>>> least have been honest.  References to UX, as your last reply has confirmed,
>>> had been basically an obfuscated equivalent of that.
>>
>> No no, I do not say "piss off". If that is what my message looked
>> like, I'm sorry for that. But I do not have any killer app or
>> something. I cannot convince you otherwise that saying it's my
>> opinion. I do not have numbers or something like that proving I have a
>> point. I wish I have. But I do understand you do not agree with me,
>> and see things different.
>>>
>>> Sorry for being harsh, but I've had it with the GNOME crowd and their ilk
>>> using just such references to handwave away any questions.
>>>
>>> There's nothing wrong with having opinions/impressions/etc.  Everyone got
>>> their own, etc.  But "I believe so, period" is not a sufficient answer to
>>> "what makes that a good idea?" and obfuscating it up is even worse.
>>
>> So, no I do not say "I believe so, period" . But I cannot convince you
>> ...and we have different opinions here.. I don't know any method here
>> of "proving having a point".
>
> One question that hasn't been answered AFAIK is how well the current
> Linux directory change notification API maps to the needs of its principal user
> (presumably Samba, and kde/gnome file managers), and a loosely
> related question of how well the change notification API maps to the
> corresponding network file system protocol operations
> (TRANSACT_NOTIFY_CHANGE) which is a fairly common operation
> sent to Samba, and obviously for the cifs/smb2/smb3 case would limit
> what types of events the client can notify the desktop/file manager about.
>
> In particular, the 10 or 15 filter flags, and the (at least) 8 events
> (add/remove/modify/rename etc.),
> available in tne network protocol AFAIK have not been matched to see if they
> match closely to the existing Linux API.

Hi,

I start working on the seperate notifyfs servers.
The whole advantage of that approach is that you can design the api
from scratch. Notifyfs is not bound to the api of inotify. There
remains the problem of mapping it to the fs event api on the host,
which will be inotify probably on linux.

At this moment the different events look like:

#define NOTIFYFS_FSEVENT_META_ATTRIB_NOTSET                     2
#define NOTIFYFS_FSEVENT_META_ATTRIB_MODE                       4
#define NOTIFYFS_FSEVENT_META_ATTRIB_OWNER                      8
#define NOTIFYFS_FSEVENT_META_ATTRIB_GROUP                      16
#define NOTIFYFS_FSEVENT_META_ATTRIB                            28

#define NOTIFYFS_FSEVENT_META_XATTR_NOTSET                      32
#define NOTIFYFS_FSEVENT_META_XATTR_CREATE                      64
#define NOTIFYFS_FSEVENT_META_XATTR_MODIFY                      128
#define NOTIFYFS_FSEVENT_META_XATTR_DELETE                      256
#define NOTIFYFS_FSEVENT_META_XATTR                             448

#define NOTIFYFS_FSEVENT_FILE_NOTSET                            512
#define NOTIFYFS_FSEVENT_FILE_MODIFIED                          1024
#define NOTIFYFS_FSEVENT_FILE_SIZE                              2048
#define NOTIFYFS_FSEVENT_FILE_OPEN                              4096
#define NOTIFYFS_FSEVENT_FILE_READ                              8192
#define NOTIFYFS_FSEVENT_FILE_CLOSE_WRITE                       16384
#define NOTIFYFS_FSEVENT_FILE_CLOSE_NOWRITE                     32768

#define NOTIFYFS_FSEVENT_MOVE_NOTSET                            65536
#define NOTIFYFS_FSEVENT_MOVE_CREATED                           131072
#define NOTIFYFS_FSEVENT_MOVE_MOVED                             262144
#define NOTIFYFS_FSEVENT_MOVE_MOVED_FROM                        524288
#define NOTIFYFS_FSEVENT_MOVE_MOVED_TO                          1048576
#define NOTIFYFS_FSEVENT_MOVE_DELETED                           2097152

#define NOTIFYFS_FSEVENT_FS_NOTSET                              4194304
#define NOTIFYFS_FSEVENT_FS_MOUNT                               8388608
#define NOTIFYFS_FSEVENT_FS_UNMOUNT                             16777216
#define NOTIFYFS_FSEVENT_FS_NLINKS                              33554432

Note that there is no such thing as watching changing xattr at this
moment right now on linux. The field st_ctime is changed, nothing
more.

Stef
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Possible to make nfs aware of a inotify watch has been set.

[Stef Bon]

2012/11/30 Stef Bon <stefbon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 2012/11/30 Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

>> match closely to the existing Linux API.
>
> Hi,
>
> I start working on the seperate notifyfs servers.
> The whole advantage of that approach is that you can design the api
> from scratch. Notifyfs is not bound to the api of inotify. There
> remains the problem of mapping it to the fs event api on the host,
> which will be inotify probably on linux.
>
> At this moment the different events look like:
>


Maybe I will add locking information as well. I see that the
/proc/locks file can be monitored as well.

To me, information is very valuable.  It would be very nice (yes my
opinion) to have information about a file on a nfs (or cifs) share
about it lockstatus, and by who, and get notified when it's unlocked.

And no nobody asked me to do so.

Stef

Re: Possible to make nfs aware of a inotify watch has been set.

[Bernd Petrovitsch]

Hi!

Since you introduced the "user experience" ignoring the fact that each
user is quite different - especially if it comes to the "Average Joes
using Ubuntu vs techies" department -, you should be prepared to eat
your own dog food:

On Fre, 2012-11-30 at 08:10 +0100, Stef Bon wrote:
[...]
> At this moment the different events look like:

Perhaps you should have used hexadecimal notation so that it is easier
for the usual/average users of source code to see the bits more easily.
In short: Please improve the user experience. Thank you.

> #define NOTIFYFS_FSEVENT_META_ATTRIB_NOTSET                     2
> #define NOTIFYFS_FSEVENT_META_ATTRIB_MODE                       4
> #define NOTIFYFS_FSEVENT_META_ATTRIB_OWNER                      8
> #define NOTIFYFS_FSEVENT_META_ATTRIB_GROUP                      16
> #define NOTIFYFS_FSEVENT_META_ATTRIB                            28
And that number seems pretty random - not a power of 2 or a bit mask or
the sum of the above.

> #define NOTIFYFS_FSEVENT_META_XATTR_NOTSET                      32
> #define NOTIFYFS_FSEVENT_META_XATTR_CREATE                      64
> #define NOTIFYFS_FSEVENT_META_XATTR_MODIFY                      128
> #define NOTIFYFS_FSEVENT_META_XATTR_DELETE                      256
> #define NOTIFYFS_FSEVENT_META_XATTR                             448
And that number seems pretty random too - not a power of 2 or a bit mask
or the sum of the above.

> #define NOTIFYFS_FSEVENT_FILE_NOTSET                            512
> #define NOTIFYFS_FSEVENT_FILE_MODIFIED                          1024
> #define NOTIFYFS_FSEVENT_FILE_SIZE                              2048
> #define NOTIFYFS_FSEVENT_FILE_OPEN                              4096
> #define NOTIFYFS_FSEVENT_FILE_READ                              8192
> #define NOTIFYFS_FSEVENT_FILE_CLOSE_WRITE                       16384
> #define NOTIFYFS_FSEVENT_FILE_CLOSE_NOWRITE                     32768

> #define NOTIFYFS_FSEVENT_MOVE_NOTSET                            65536

And from here own I'm too lazy to calculate (or even guess) if these are
actually powers of 2 or not.
> #define NOTIFYFS_FSEVENT_MOVE_CREATED                           131072
> #define NOTIFYFS_FSEVENT_MOVE_MOVED                             262144
> #define NOTIFYFS_FSEVENT_MOVE_MOVED_FROM                        524288
> #define NOTIFYFS_FSEVENT_MOVE_MOVED_TO                          1048576
> #define NOTIFYFS_FSEVENT_MOVE_DELETED                           2097152
> 
> #define NOTIFYFS_FSEVENT_FS_NOTSET                              4194304
> #define NOTIFYFS_FSEVENT_FS_MOUNT                               8388608
> #define NOTIFYFS_FSEVENT_FS_UNMOUNT                             16777216
> #define NOTIFYFS_FSEVENT_FS_NLINKS                              33554432

MfG,
	Bernd
-- 
Bernd Petrovitsch                  Email : bernd-JY8rjfDgnXcb9sJ47jD7nuTv7YV0F9Eg@public.gmane.org
                     LUGA : http://www.luga.at