From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH] cifs: remove dnotify thread code Date: Sat, 10 Jan 2009 01:41:28 +0000 Message-ID: <20090110014128.GF1972@shareable.org> References: <1231424128-5598-1-git-send-email-jlayton@redhat.com> <524f69650901080623s228c343eka791c089c878167@mail.gmail.com> <20090109000708.GC12848@shareable.org> <20090108202824.69fcac39@tleilax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Steve French , linux-cifs-client@lists.samba.org, linux-fsdevel@vger.kernel.org To: Jeff Layton Return-path: Received: from mail2.shareable.org ([80.68.89.115]:59735 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755142AbZAJBla (ORCPT ); Fri, 9 Jan 2009 20:41:30 -0500 Content-Disposition: inline In-Reply-To: <20090108202824.69fcac39@tleilax.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Jeff Layton wrote: > > 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. The notify API needs the ability to report, in general, whether you'll get notify events from a particular filesystem / file / directory / whatever-condition anyway. And also whether you get events for all (remote) changes, or just local changes. You might as well _try_ to get a delegate, and if you fail, tell the caller that it won't receive notifications on this file and will have to poll - just like most other remote filesystems. -- Jamie