[Fwd: Re: missing code in fcntl_dirnotify]

Steve French smfrench at austin.rr.com
Mon Aug 18 02:42:16 GMT 2003


 Interesting discussion on change notify follows

-------- Original Message --------
Subject: Re: missing code in fcntl_dirnotify
Date: Sat, 16 Aug 2003 15:43:42 +0100
From: Jamie Lokier <jamie at shareable.org>
To: Steve French <smfrench at austin.rr.com>
CC: linux-fsdevel <linux-fsdevel at vger.kernel.org>
References: <3F3E3D80.3020208 at austin.rr.com>



Steve French wrote:
>  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).

(This whole message assumes the server doesn't delay notifications
internally - only the network and network protocol does).

Using cifs change notify does not completely fix the problem of
invalid cache results, because there is a latency in the notification
due to the network.  The will be times when the result you assume is
different to the result you'd get if you issued a request to the
server, because the notification is in flight.

However, if when you want to validate the cached dentry you wait until
at least one request has been sent over the cifs connection (_any_
request, from any process, will do), and until a response has been
received for that or any subsequent request, then you have safely
validate the dcache entry.

The trick, when a protocol is run over TCP (such as CIFS, or NFS over
TCP), is to look at your global queue of requests when you want to
revalidate something.  If it's non-empty, just take the serial number
of the first one which hasn't been transmitted yet, and wait until you
receive a response for that serial number or any later one.  If the
queue is empty, then generate a request, whether it's the equivalent
of STAT, NOP or the actual thing that you are checking anyway, and use
that as the serial number threshold to wait on.  If none of the
responses prior to the serial you are waiting for is a change
notification, you can assume your cached value was valid at the time
you started this whole procedure, and therefore return the value.

-- Jamie







More information about the samba-technical mailing list