Re: [nfsv4] Issue 21: pnfs EOF handling

Trond Myklebust wrote:
> On Tue, 2006-07-11 at 06:37 -0400, Benny Halevy wrote:
> 
>>Trond Myklebust wrote:
>>
>>>Why would this be better than the lazy alternative (i.e. recall the
>>>layout when someone else requests a GETATTR call)?
>>> 
>>>
>>
>>I think there's no real need to recall the layout for files and objects 
>>since only data and attributes
>>were changed by the writer. Wouldn't using CB_GETATTR be more efficient 
>>in this model?
> 
> 
> I suppose so. At least if the other client is just reading the file.
> 
> Note that the client is not guaranteed to have a delegation for the
> file, so it would be a change in behaviour for CB_GETATTR.
> 
> Also note that the concept of uncertainty in the file length is hardly
> new: we've had that ever since we introduced write caching. By that
> precedent, it would be perfectly justifiable to allow the reader to EOF
> when it hits the old end-of-file. Why does pNFS need better caching
> semantics than NFS here?
> 
While the semantics may seem better than NFS I don't think they really 
are.  Basically you are getting what pretty much any NFS server gives 
you --- the ability for a client that issued a read to see the latest 
data comitted at the NFS server.  I agree this is better than 
open-close, but it is what you get today.  Also, since the EOF callback 
was proposed for blocks, we thought we could make use of it.

You are correct that it would be justifiable to return EOF to the 
reader.  But as I mentioned earlier, it is slightly harder for the 
reader to obtain the new EOF (it can't piggyback getattr calls on the 
read).

I think we are arguing a minor point here.  The EOF callback is an 
optimization.

-Garth

> Cheers,
>   Trond

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4