linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] fsnotify - Add support for ignoring self initiated events
@ 2013-10-16 19:13 Jim Lieb
  2013-10-16 19:13 ` [PATCH 1/3] fsnotify: add support for ignoring events from self Jim Lieb
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Jim Lieb @ 2013-10-16 19:13 UTC (permalink / raw)
  To: eparis; +Cc: linux-fsdevel, bfields, jlayton


This change has been discussed at NFS Bakeathon this Sept and there were
no change request comments.  Please ACK and merge.  They are based on
3.12-RC5.
 
Our use case is an NFS+pNFS+9P user mode server.  We need to keep our
caches (dentry+inode) current with the underlying kernel.  To do this we
need inotify to feed filesystem events to our upcall infrastructure.  We
place a watch on each directory we have cached and any events that morph
that directory would cause invalidates and/or updates to those entries.

The current fsnotify subsystem does most of what we want but implicit in
the dnotify/inotify/fanotify interfaces is the assumption that the watcher
is an "innocent bystander" whose sole/main function is to draw/remove icons
on a window when someone else adds/removes things from a directory.  Part
of our use case is that the ganesha.nfsd server is co-resident with a CIFS
server which is also exporting the same filesystem(s) and service management
tools that modify the filesystem structure (snapshots and volume adds...).
The current inotify interface will send up all events but if both servers
are equally busy we get two bad results:

1. each server gets twice the traffic it really needs (theirs and ours).

2. there is no simple way to tell their events from ours in each event.

This patch set adds a new watch/mark flag (FS_IGNORE_ME) to fsnotify.
Setting this flag causes the watching process's pid to be stored in the
mark for the inode.  The flag is tested at event time and if set and if
the pid of the event generating process matches the stored pid, the event
is ignored, saving the overhead of allocating an event, pushing it up to
user space only to be rejected. Being in fsnotify makes it available to
any notification scheme built on fsnotify.

The IN_IGNORE_ME flag bit is added to inotify.  When set, none of the other
event flags will generate an event if the calling process generated the
event.  Given the current way that inotify_add_watch() validates the flags
argument, discovering whether the kernel supports the flag requires an
extra test (set the watch and generate an event...).

The FAN_IGNORE_ME flag bit does the same for fanotify.  fanotify in current
kernels will return an EINVAL error if this bit is set, making discovery
easier.  One performance side effect is that this flag eliminates the need and
overhead for a test of my_pid == e.pid in the event processing loop.

We chose inotify rather than the current fanotify because we need the extra
events that fanotify cannot (currently) support.  dnotify was not touched
because it is both obsolete and its api makes this extension difficult.

This change works with single threaded or NPTL based applications.  We
do not attempt to address the more complex case of multiple processes
using shared memory. That would require additional code in the application
to sort out events.

Thanks

Jim Lieb, NFS Ganesha project

^ permalink raw reply	[flat|nested] 5+ messages in thread
* RFC: fsnotify - Add support for ignoring self initiated events
@ 2013-09-04 18:30 Jim Lieb
  2013-09-04 18:31 ` [PATCH 1/3] fsnotify: add support for ignoring events from self Jim Lieb
  0 siblings, 1 reply; 5+ messages in thread
From: Jim Lieb @ 2013-09-04 18:30 UTC (permalink / raw)
  To: linux-fsdevel

Our use case is an NFS+pNFS+9P user mode server.  We need to keep our
caches (dentry+inode) current with the underlying kernel.  To do this we
need inotify to feed filesystem events to our upcall infrastructure.  We
place a watch on each directory we have cached and any events that morph
that directory would cause invalidates and/or updates to those entries.

The current fsnotify subsystem does most of what we want but implicit in
the dnotify/inotify/fanotify interfaces is the assumption that the watcher
is an "innocent bystander" whose sole/main function is to draw/remove icons
on a window when someone else adds/removes things from a directory.  Part
of our use case is that the ganesha.nfsd server is co-resident with a CIFS
server which is also exporting the same filesystem(s) and service management
tools that modify the filesystem structure (snapshots and volume adds...).
The current inotify interface will send up all events but if both servers
are equally busy we get two bad results:

1. each server gets twice the traffic it really needs (theirs and ours).

2. there is no simple way to tell their events from ours in each event.

This patch set adds a new watch/mark flag (FS_IGNORE_ME) to fsnotify.
Setting this flag causes the watching process's pid to be stored in the
mark for the inode.  The flag is tested at event time and if set and if
the pid of the event generating process matches the stored pid, the event
is ignored, saving the overhead of allocating an event, pushing it up to
user space only to be rejected. Being in fsnotify makes it available to
any notification scheme built on fsnotify.

The IN_IGNORE_ME flag bit is added to inotify.  When set, none of the other
event flags will generate an event if the calling process generated the
event.  Given the current way that inotify_add_watch() validates the flags
argument, discovering whether the kernel supports the flag requires an
extra test (set the watch and generate an event...).

The FAN_IGNORE_ME flag bit does the same for fanotify.  fanotify in current
kernels will return an EINVAL error if this bit is set, making discovery
easier.  One performance side effect is that this flag eliminates the need and
overhead for a test of my_pid == e.pid in the event processing loop.

We chose inotify rather than the current fanotify because we need the extra
events that fanotify cannot (currently) support.  dnotify was not touched
because it is both obsolete and its api makes this extension difficult.

Please review and comment.  If it is acceptable, please ACK and merge.

Thanks

Jim Lieb, NFS Ganesha project


^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-10-16 19:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-16 19:13 [PATCH 0/3] fsnotify - Add support for ignoring self initiated events Jim Lieb
2013-10-16 19:13 ` [PATCH 1/3] fsnotify: add support for ignoring events from self Jim Lieb
2013-10-16 19:13 ` [PATCH 2/3] fanotify: enable support for ignoring self generated events Jim Lieb
2013-10-16 19:13 ` [PATCH 3/3] inotify: enable support to ignore " Jim Lieb
  -- strict thread matches above, loose matches on Subject: below --
2013-09-04 18:30 RFC: fsnotify - Add support for ignoring self initiated events Jim Lieb
2013-09-04 18:31 ` [PATCH 1/3] fsnotify: add support for ignoring events from self Jim Lieb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).