mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Robert Love <rml@novell.com>
Cc: Steve French <smfrench@austin.rr.com>, linux-kernel@vger.kernel.org
Subject: Re: which ioctls matter across filesystems
Date: Fri, 29 Apr 2005 16:42:40 -0400	[thread overview]
Message-ID: <1114807360.12692.77.camel@lade.trondhjem.org> (raw)
In-Reply-To: <1114805033.6682.150.camel@betsy>

fr den 29.04.2005 Klokka 16:03 (-0400) skreiv Robert Love:
> On Fri, 2005-04-29 at 15:53 -0400, Trond Myklebust wrote:
> 
> > We are discussing the equivalent of dnotify as a potential candidate for
> > the first minor version of NFSv4, but not inotify.
> > The purpose of our dnotify implementation is address the needs of things
> > like file browsers that don't really care about synchronous notification
> > of changes, but that do currently cause a lot of unnecessary traffic on
> > the wire due to constantly polling stat() and doing readdir() updates.
> > The jury is still out as to whether or not the callbacks actually do
> > reduce on-the-wire traffic, though, so we may drop it.
> 
> What about inotify makes it insufficient for your needs?

Nothing, if you are just tracking changes that are made by local
processes.

For remote filesystems like CIFS and NFS, however, there may be
applications that want to monitor changes that are made directly on the
server by other clients. In the above paragraph, I'm therefore referring
to a debate about whether or not adding officially sanctioned NFSv4
protocol support for something like dnotify/inotify makes sense.

The problem is that having the server call back a bunch of clients every
time a file changes does not really scale too well. The current
dnotify-like proposal therefore specifies that notification is not
synchronous (i.e. there may be a delay of several seconds), and that the
server may want to group several notifications into a single callback.
(if interested, you can view the current proposal on
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-directory-delegation-01.txt)


> > What kind of real-world applications exist out there that need inotify
> > functionality, and what sort of requirements do they have (in particular
> > w.r.t. the notification mechanism)?
> 
> A few worksets:
> 
> 	- Current users, such as FAM and Samba, that need simple file
> 	  change notification
> 	- Random applications that want to watch a file or two
> 	- The Linux desktop
> 	- Real-time live-updating indexing systems, such as Beagle,
> 	  that compete with f.e. Apple's Spotlight.

Right, but I assume that most of the use-cases (with possible exception
of FAM) do not really involve tracking changes made by other NFS
clients. Although I imagine in particular that the real-time indexing
system workload trying to run on several clients and tracking the same
files at the same time might be a lot of fun...

I'm therefore asking whether or not there is a killer-app out there that
we need to support and that does want to track changes made by other
clients. File browsers are more or less the only thing that come to
mind.

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>


  reply	other threads:[~2005-04-29 20:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-29 19:22 Steve French
2005-04-29 19:53 ` Trond Myklebust
2005-04-29 20:03   ` Robert Love
2005-04-29 20:42     ` Trond Myklebust [this message]
2005-04-29 20:47       ` Robert Love
2005-04-29 21:13         ` Trond Myklebust
2005-04-29 21:22           ` Steve French
2005-04-29 21:38             ` Trond Myklebust
2005-04-29 20:55       ` Steve French
2005-04-29 20:57         ` Robert Love
2005-04-29 21:05           ` Steve French
2005-04-29 20:47     ` Steve French
2005-04-29 20:50       ` Robert Love
2005-04-29 21:00         ` Steve French
2005-04-29 20:32   ` Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1114807360.12692.77.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@novell.com \
    --cc=smfrench@austin.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®