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

From: [email-masked]
Date: Fri, 11 Aug 2006 11:39:21 -0400

On Thu, 10 Aug 2006 16:27:14 -0400, Trond Myklebust wrote:
> On Thu, 2006-08-10 at 15:35 -0400, fridella_stephen at emc.com wrote:
> > So are you saying that, in general, a client that receives a
> > LAYOUTRECALL should not flush dirty data before returning the
> > LAYOUT?  Or are you saying that we should not recall a layout
> > from a client on truncate?
> 
> LAYOUTRECALL should definitely not require the client to flush any
> cached dirty data. It is _not_ an instrument for managing caching.

Ok, the rest of your response makes sense in the light of this
principle.

> I'd advocate recalling any READ layouts for clients on truncate, but I
> don't see why we should need to recall WRITE layouts.

Unless we make the truncate a no-op at the server, the blocks beyond
the new eof will be freed by the file system.  I suppose playing games
where we reduce the file's reported size but leave the blocks allocated
is possible, but it introduces a bunch of complexity into our fs
implementation and will probably cause problems for fsck as well...

But in any case, as long as the RECALL does not affect cached data
at the client, you don't have an issue with it, correct?

Now that I understand the caching part (finally!) I still think there
is value in a hint for LAYOUTRECALL.  While the RECALL does not cause
the client to flush data, it will cause the client to commit changes in the
layout for any blocks which have already been written.  These changes
must be processed by the server, recorded in the fs transaction log, etc.
In the truncate case, all such changes will be wiped out once the truncate
occurs, meaning that the work to commit them was wasted effort.  If a
LAYOUTRECALL contains a hint indicating it is the result of a truncate,
the client can simply return the LAYOUT without committing changes.

Since we have already allocated a field for one type of LAYOUTRECALL
hint ("layoutchanged"), why not use the field more generically to
carry multiple kinds of useful hints?

-Steve

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

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 11 Aug 2006 11:54:01 -0400

> implementation and will probably cause problems for fsck as well...

Yeah. Upon further thought, I came to the conclusion that we should in
any case always recall block layouts that have committed data, since
those blocks will be fully visible to the client that is doing the
truncate, and so really do need to be truncated.

> at the client, you don't have an issue with it, correct?

Right.

> the client can simply return the LAYOUT without committing changes.

I s'pose so.

> carry multiple kinds of useful hints?

Examples?

Cheers,
  Trond