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

[Steve French]

It would be really helpful if we could get directory delegations over
CIFS (or SMB2) so we could avoid worrying about notifications of
directory change events, but in practice it seems like the performance
impact (to Windows servers, Samba servers, and various NAS filers) of
the existing "multi-shot" directory change notifications have not been
too bad.

File change notifications are helpful in some environments, and with
leases (oplocks) don't even have to be sent to the server but it seems
like directory change notifications (adding/deleting files in a
directory) is the more "user visible"

Interesting the notify code was originally added to Linux to support
Samba (at Tridge's request many years ago) which needed it to handle
Windows (client) explorer desktop (which calls the Windows equivalent
notify)

On Fri, Jan 9, 2009 at 7:41 PM, Jamie Lokier <jamie at shareable.org> wrote:
> 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
>



-- 
Thanks,

Steve