Subject: RE: [nfsv4] CB_NOTIFY_LOCK

From: Peter Varga <[email-masked]>
Date: Tue, 22 Aug 2006 23:14:48 -0400

> -----Original Message-----
> From: Trond Myklebust [mailto:[email-masked]] 
> Sent: Tuesday, August 22, 2006 5:21 PM
> To: Peter Varga
> Cc: [email-masked]; [email-masked]
> Subject: RE: [nfsv4] CB_NOTIFY_LOCK
> 
> 
> On Tue, 2006-08-22 at 16:42 -0400, Peter Varga wrote:
> > What about OPENs for WRITE ?
> 
> What about them? The only difference between an OPEN for WRITE and an
> OPEN for READ is that we've decided that OPEN for WRITE must be
> exclusive. If applications still need to obey the 
> close-to-open caching
> model in order to deal with the case where the client loses the
> delegation (or fails to obtain it in the first place), then why do you
> care?

My only point was that a client needs WRITE delegation in order to locally
handle requests to open a file for write or read|write access.

> > Why don't write delegations really allow you to go beyond 
> the existing
> > close-to-open caching model? My understanding is that it 
> allows the client
> > to write locally, and flush later.
> 
> That can be a real win in the case where you have a single client
> reading and writing the same data, however as soon as you want to do
> anything more than open the file and manipulate the data, you usually
> need to return the delegation first. In addition, pretty much any
> operation by other clients requires either a slow CB_GETATTR 
> callback or
> a delegation recall.
> 
> In practice, most clients are probably still flushing the data on
> close() simply because it makes returning the delegation fast.
> 
> Cheers,
>   Trond
> 

If users are working out of their own directories, CB_GETATTR is not very
frequent at all. We're getting into specific use cases here.

As for more than data manipulation, maybe we should consider ways to make
write delegations more powerful by allowing the client to do even more
locally (modifying attributes, file names, etc)... future :)

Peter

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4