Subject: RE: [NFSv4] Hints for client on LAYOUTRECALL

From: [email-masked]
Date: Wed, 9 Aug 2006 09:59:17 -0400

Ok I see... so in the NFS caching model, a truncate from
client A should not effect dirty data cached at client B.

Just so I'm clear, does this mean the behavior where the
block/volume pNFS server recalls the layout from B when
it receives the truncate from A, and B flushes its dirty data,
then commits its layout, and finally the file is truncated
on the server, is also incorrect?

It seems that way, since in this case, as well as the clobber
case, the application on client B will lose its cached data
before it calls close...
-Steve

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]] 
> Sent: Wednesday, August 09, 2006 12:26 AM
> To: [email-masked]
> Subject: Re: [NFSv4] Hints for client on LAYOUTRECALL
> 
> On Tue, Trond Myklebust wrote:
> > On Tue, 2006-08-08 at 17:07 -0400, [email-masked] wrote:
> > 
> > > If the CB_LAYOUTRETURN contains a hint indicating that the
> > > callback is the result of a truncate, the client can choose to
> > > simply clobber the cached data and return the layout without
> > > commit.  This saves processing time at the client, the server,
> > > and the data server.
> > 
> > That would be incorrect behaviour w.r.t. the NFS caching model. A
> > truncate by another client should _not_ cause cached data to be
> > clobbered.
> 
> I agree.  This is a change in behavior from what exists today
> at the NFS client.  It is best left as it is.
> 
> Spencer
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 09 Aug 2006 10:15:23 -0400

> client A should not effect dirty data cached at client B.

Exactly. The possible exception to this rule is if client A holds a
delegation. If so, then the act of truncating the data will cause the
delegation to be recalled, at which point the client may choose to flush
its data (which will subsequently be lost).
Strictly speaking, though, that client behaviour is a violation of
close-to-open semantics.

> case, the application on client B will lose its cached data

Yes.

I think the situation is slightly more hairy when it comes to a READ
layout. In that case, the layout probably should be recalled, since the
client would normally expect that subsequent READs to the metadata
server will see the effect of the truncation.
The close-to-open cache consistency model does not actually require this
either, though, since clients are supposed to avoid changing the file
while there are other readers.

Cheers,
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 09 Aug 2006 10:17:36 -0400

> Strictly speaking, though, that client behaviour is a violation of

Err.... I meant "The possible exception to this rule is if client B
holds...."

errno = ENOCOFFEE;

Cheers,
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 09 Aug 2006 10:56:29 -0400

Note that there are several cases where the blocks world gets
"interesting" w.r.t. the NFS caching model.

For instance any operation where cache consistency _is_ important (e.g.
the client holds a byte range lock for a write that is not block/extent
aligned) and which requires a read-modify-write in order to succeed is
problematic. I'd suggest that clients should probably do this using the
metadata server, which can recall outstanding layouts on the affected
region in order to enforce atomicity.

Is this sort of scenario discussed in the latest blocks draft?

Cheers,
  Trond