From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: missing code in fcntl_dirnotify Date: Sat, 16 Aug 2003 09:19:44 -0500 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <3F3E3D80.3020208@austin.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from ms-smtp-02.texas.rr.com ([24.93.36.230]:16791 "EHLO ms-smtp-02.texas.rr.com") by vger.kernel.org with ESMTP id S272942AbTHPOTp (ORCPT ); Sat, 16 Aug 2003 10:19:45 -0400 Received: from austin.rr.com (cs24243238-35.austin.rr.com [24.243.238.35]) by ms-smtp-02.texas.rr.com (8.12.5/8.12.2) with ESMTP id h7GEJiTX005869 for ; Sat, 16 Aug 2003 09:19:44 -0500 (CDT) To: linux-fsdevel List-Id: linux-fsdevel.vger.kernel.org Your point about safe dentry caching is a good one and I have meant to experiment with the idea of requesting to the server (via cifs change notify) notification for this purpose (since I am caching dentry info for about a second which is unsafe but similar to what nfs does - although I am safely caching inode data across the network via the cifs oplock mechanism) but was concerned about performance. The particular use that a few people were asking me about recently was using the cifs vfs for distributed backup change notification (presumably because a wide variety of servers already handle the change notification subset of the CIFS protocol) and thus my small patch suggestion (which I will code up and experiment with next week). Jamie Lokier wrote: >Stephen Rothwell wrote: > >>>notification to the underlying network filesystem, it can not know to >>>read the updated inode->i_dnotify_mask Is there any objection why >>>dnotify_parent should not be added to ksysm.c and to adding an optional >>>inode_operation for change_notify so filesystems that can support change >>>notify (cifs, nfs, presumably afs etc.) could do change notify to the >>>proper kernel routine(dnotify_parent)? >>> >>No objection whatsoever. At the time we implemented dnotify, we did not >>need it to work on networked file systems (at least for remote events) >>and we were not confident enough of ourselves or our understanding of >>the file system code (locking in particular) to attempt this. So we >>documented it ... :-) (see Documentation/dnotify.txt) >> >>You probably need to add __inode_dir_notify as well (I think). >> > >Note that local dnotify has well defined ordering, such that if you >know the underlying filesystem is local, stat() results can be safely >cached until a dnotify event is received, and dnotify events that are >sent are available to the target task immediately, without delay. > >This is quite useful, when recreating a cached web page or program >file would require a stat() of all its component source files and >databases, as you can avoid all of them and just see whether you >received a dnotify before the page request. This makes it feasible to >do accurate cacheing on every request. > >At the moment, it's necessary to only use this feature if it's known >to be a local filesystem time, or if it's known that only the local >host modifies the files. > >When dnotify is added for network filesystems, it seems likely that >the well defined ordering would be relaxed - that you'd expect to see >the dnotify _eventually >_, rather than guaranteed to see it as soon as >a file is changed. (NFS does not return up to date stat() results >either, so dnotify is not the only thing which is relaxed). > >It would be great if there were some way for the application to be >told which kind of dnotify ordering it is getting (immediate or >delayed), and of course whether it will get them at all for files >modified remotely. > >Cheers, >- Jamie >