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@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html