[linux-cifs-client] Re: [PATCH] cifs: remove dnotify thread code

Jeff Layton jlayton at redhat.com
Fri Jan 9 01:28:24 GMT 2009


On Fri, 9 Jan 2009 00:07:08 +0000
Jamie Lokier <jamie at shareable.org> wrote:

> Steve French wrote:
> > We really need to revisit the dnotify/inotify code ... the SMB spec
> > lists what the protocol allows, but AFAIK no one has had a chance to
> > prototype this.   It is among the highest priority features still
> > needed to implement in cifs.
> > 
> > As we have talked about before, dnotify (or inotify) is even more
> > useful for network file systems than local file systems (since the
> > alternative, polling, is too expensive to do over the network).   CIFS
> > and SMB2 protocols, unlike NFS, has a mechanism to handle dnotify, but
> > mapping it to the VFS has not been investigated sufficiently
> 
> I think NFSv4 can do it with delegations, although the exact semantics
> an app could rely on would be different.
> 

I don't think delegations help here since it's entirely up to the
server whether to grant one or not. I've only given inotify/dnotify a
drive-by look, but I'm pretty sure you'd want the client to be able to
set up events to monitor.

> There are several different kinds of notify that apps could use for
> different purposes: 1. Queued (an event is posted after a change, will
> eventually reach the app).  2. Coherent (the app can ask "any
> notifications for me" and if the answer is no, it can be sure that an
> attribute/data read issued prior to asking would have yielded what the
> app already cached; a sort of app cache validation).  3. Lease (the
> app is notified and must respond prior to a change being allowed to
> proceed).
> 
> These form a hierarchy: if the OS/filesystem provides Lease (3), the
> app can use it in place of Coherent (2) and Queued (1).  If the
> OS/filesystem provides Lease (3) or Coherent (2), the app can use
> either in place of Queued (1).
> 
> All of these have different, useful applications.  GUIs like Nautilus
> are happy with Queued (1).  For content indexers, it depends how you
> want them to behave, and how up to date they should seem.  For
> something which computes things from file contents or attributes, such
> as (possible beneficiaries) any scripting language, Make, Git, JIT
> system, or web templating system, it needs Coherent (2) notifications;
> Queued (1) is not reliable for caching.  Lease (3) is potentially
> useful for distributed databases.
> 
> For CIFS/SMB it looks like all three could be implemented, in
> different ways.  I'm not sure if NFSv4 can do Queued, but I think with
> delegations it can do Coherent and Lease.
> 
> For local filesystems, I think Linux provides Coherent but I haven't
> looked closely.  If not, it provides Queued.
> 
> Al Viro said (long ago) apps should not rely upon timely
> dnotify/inotify events, and therefore should not use them for
> consistent app caching.  However, timely delivery isn't required,
> what's required is that reading the inotify descriptor (or reading a
> flag set by delivery of the dnotify signal / inotify SIGIO?) will
> definitely return an event if the corresponding file change has become
> observable by other means.  It is about ordering guarantees.
> 
> If there is a revamp of the fsnotify code for networking especially,
> please at least have a little think about the different event delivery
> models and what apps can expect, when which semantics to support.  The
> different models are each useful, and may involve different parts of
> the networked filesystem protocol.
> 

CIFS has a call that tells the server to notify the client when a
directory changes (NT_TRANSACT_NOTIFY_CHANGE). This, in principle would
allow us to implement a subset of inotify/dnotify across the network.
I'm not sure which kind we'd be able to implement (probably "queued
at best).

I wholeheartedly agree however that this is something that we should
implement with care. What little code there was in place for this is
now mostly gone. The only thing that remains is this kthread that
currently serves no purpose. When/if we do this, we'll want to
reimplement all of this from the ground up anyway.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list