Re: Determining interrim meeting interest

On Mon, Dec 6, 2010 at 2:33 PM,  <david.noveck <at> emc.com> wrote:
> I'll volunteer to create a document plus
> slide set for the pNFS possible-errata.  My promise is to have both in
> people's hands one week before the meeting.  Please send me suggestions.

Here are the issues I'm dealing with that immediately come to mind:

What does it mean if the server sends a bulk CB_LAYOUTRECALL with
iomode != ANY?  Should this even be allowed, given the strict "dump
all layoutstate" requirements of the bulk recalls.

How should the server respond to a LAYOUTGET with an open stateid when
it has already handed out a layoutstateid?  Should it consider this a
signal that the client has forgotten previous state, or should it
assume that this is one of several parallel LAYOUTGETs sent by the
client?
The former choice forces serialization of the LAYOUTGETs with open
stateids.  The second requires the forgetful client to remember the
layoutstateid when forgetting the layout, and raises the question of
why doesn't the client just always send an openstateid in LAYOUTGET?

Does the file layout ever *have* to send a LAYOUTCOMMIT.

If the server sends a CB_LAYOUTRECALL, what client responses
necessitate updating the clients layoutstateid seqid?  Clearly OK, but
isn't NOMATCHING also a "successful" response that should update the
clients view?  What about other errors, especially DELAY?

What happens when the client sends a close for a file with layouts
marked roc without sending the LAYOUTRETURN?  What serialization
requirements are there if this is considered an implicit LAYOUTRETURN?

Fred
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4