Re: [RFC PATCH -v4 00/14] fsnotify, dnotify, and inotify

[Eric Paris <eparis@redhat.com>]

On Mon, 2008-12-22 at 14:59 -0500, C. Scott Ananian wrote:
> On Sun, Dec 21, 2008 at 10:22 PM, Eric Paris <eparis@redhat.com> wrote:

> > In any case, I'm going to let your thoughts rattle around in my brain
> > while I'm still trying to rewrite inotify and dnotify to a better base.
> > My first inclination is to stop using inotify and start using fanotify.
> > Abandon filenames and start using device/inode pairs and you get
> > everything you need.  But I'm certain that isn't that case    :)
> 
> Well, except for being able to recreate the path from the inode,
> without which ability inode numbers without directory notifications
> are pretty useless.

fanotify doesn't have directory notifications.  You get notifications
about the individual inodes.  I don't have mv tracking, and I'm not sure
how much trouble it'll be.  Maybe not that bad since a mv doesn't have
to deliver the fd to userspace.  I promise to think about how to make
this better for you.  In any case, you can get pathnames, dev, and inode
very quickly.

> BTW, I had some difficulty discovering the exact userland API you were
> proposing for fanotify.  I eventually found in it the 'v1' and 'v2'
> set of fanotify patches, before the split to fsnotify, but it would be
> nice to see it restated in an easier-to-find place.  'google fanotify'
> turns up:
>    http://lwn.net/Articles/303277/
> as the second hit, which is reasonable, but
>    http://people.redhat.com/~eparis/fanotify/21-fanotify-documentation.patch

This is probably the best there is ATM.  It includes a program which
uses all of the fanotify functionality I wrote.

> seems better?  I note that fanotify doesn't actually seem to return
> the relevant inode number from (say) a CLOSE_WAS_WRITABLE event; I've
> got to stat /proc/self/fd/<fd> to get that?

For pathname you readlink on /proc/self/fd/[event->fd]

For dev and ino you stat [event->fd]

where event was filled from your getsockopt call.

In any case, event coallessing seems like it needs to work by walking
the notification queue starting at the back and working forwards.  If
you find a duplicate just drop.  If you find a mv, place this one at the
end.  Kinda sucks that we are taking and O(1) operation and making it
O(n).

At least with fanotify you don't have mv races, since you have an open
fd which still gives you the access you need even if it mv'd.

don't worry I won't forget your thoughts.

-Eric