Subject: [nfsv4] pnfs minor issues (from last IETF)

From: Garth Goodson <[email-masked]>
Date: Tue, 13 Jun 2006 17:30:43 -0700

Went through my notes and found the following from the last IETF (I 
think they are mostly nice-to-have):

- possible name change for pnfs reclaim bit (a little confusing as it is)
- clearer text on semantics of overlapping layouts handed out by server
- best practices for when a client should do a LAYOUTCOMMIT (Trond)

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

---

From: Benny Halevy <[email-masked]>
Date: Wed, 14 Jun 2006 12:08:05 +0300

> - clearer text on semantics of overlapping layouts handed out by server

I'm working on that for the pnfs-obj Internet Draft.

Benny

---

From: Benny Halevy <[email-masked]>
Date: Wed, 14 Jun 2006 15:11:38 +0300

There are quite a few comments in 
draft-ietf-nfsv4-minorversion1-02.txt that need our 
attention. I'm not sure which of these are tracked in the 
issue tracker...

Comment.1: Determine private range of layout types

I think this is important to resolve. I don't see and 
technical difficulty with defining such a range and a 
mechanism (IANA?) to register new layout types.

Comment.2: move striping information up to the generic 
layout level?

There doesn't seem to be much interest in doing so. I 
suggest removing this comment.

Comment.3: it has been suggested that the HINT is a well 
defined type other than pnfs_layoutdata4, similar to 
pnfs_layoutupdate4.

Is there any concrete proposal to discuss?

Comment.4 and 5: (Resolving server callback races with 
sessions) We need to consider the clients' options here, and 
describe them...  NFS4ERR_DELAY has been discussed as a 
legal reply to CB_RECALL?

These should probably be address in conjunction with Tom's 
proposal.

Comment.6: Should LAYOUTRETURN be modified to handle FSID 
callbacks?

I'm supporting doing that. It sounds appropriate as a 
symmetric operation to a cb_layoutrecall for RECALL_FSID.

Benny

---

From: Garth Goodson <[email-masked]>
Date: Wed, 14 Jun 2006 09:48:44 -0700

Benny Halevy wrote:
> There are quite a few comments in draft-ietf-nfsv4-minorversion1-02.txt 
> that need our attention. I'm not sure which of these are tracked in the 
> issue tracker...
> 
> I think this is important to resolve. I don't see and technical 
> difficulty with defining such a range and a mechanism (IANA?) to 
> register new layout types.
> 
I agree we need to resolve this.  I've created Issue 57 to track it.

> Comment.2: move striping information up to the generic layout level?
> 
> There doesn't seem to be much interest in doing so. I suggest removing 
> this comment.
> 
Agreed.  I'll add an issue to remove this text.

> Comment.3: it has been suggested that the HINT is a well defined type 
> other than pnfs_layoutdata4, similar to pnfs_layoutupdate4.
> 
I'm in the process of writing something up.  Issue 55 in tracker.

> Comment.4 and 5: (Resolving server callback races with sessions) We need 
> to consider the clients' options here, and describe them...  
> NFS4ERR_DELAY has been discussed as a legal reply to CB_RECALL?
> 
> These should probably be address in conjunction with Tom's proposal.
> 
Yeah, let's see what they come up with first...  I'm going to add this 
comment to Issue 19.

> Comment.6: Should LAYOUTRETURN be modified to handle FSID callbacks?
> 
> I'm supporting doing that. It sounds appropriate as a symmetric 
> operation to a cb_layoutrecall for RECALL_FSID.
> 
This is fine, although I'm somewhat ambivalent.  It will help when read 
layouts are held, but with layouts that require layoutcommits the 
layoutreturn can be sent in the same compound as the commit.  Also, if 
we support layoutreturn by FSID then you won't be able to specify byte 
ranges -- it will have to be assumed that the whole layout is returned.

I can write up a proposal and post it for review.  I have created issue 
58 to track it.

-Garth