Spencer Shepler | 6 Dec 2010 19:54
Picon
Favicon

Re: Determining interrim meeting interest


> -----Original Message-----
> From: Haynes, Tom [mailto:Thomas.Haynes <at> netapp.com]
> Sent: Monday, December 06, 2010 10:50 AM
> To: Benny Halevy
> Cc: Spencer Shepler; nfsv4 <at> ietf.org
> Subject: Re: [nfsv4] Determining interrim meeting interest
> 
> 
> 
> On Nov 30, 2010, at 8:47 AM, "Benny Halevy" <bhalevy <at> panasas.com> wrote:
> 
> > On 2010-11-29 20:10, Spencer Shepler wrote:
> >>
> >> I have received two responses of interest to my initial query about
> >> an interim meeting.  Seems a little sparse to hold an interim meeting.
> >>
> >> Thus, please send me email if you are interested in attending.
> >>
> >> My suggestion for a 1.5 day meeting are:
> >>
> >>    Feb 13th - 14th.
> >>
> >> This is the two days prior to the FAST '11 conference.
> >>
> >> Other date suggestions are most certainly welcome.
> >>
> >> Ideas for agenda items?  Let me know that as well.
> >
> > I suggest discussing:
(Continue reading)

david.noveck | 6 Dec 2010 20:33

Re: Determining interrim meeting interest

I agree with Spencer.  There is no reason to exclude these errata (or
possible errata) from the list.  The question is what is the proper
priority ordering of the list if we find out that there is more to
discuss than time.

It is troubling that we have these uncertainties that are creating
difficulties for implementation.  To me that makes the priority higher.

I can see Tom's concern that there is v4.2 stuff that does need to get
some progress made, despite the high priority for clearing up the pNFS
(and other such?) stuff.  Maybe the right thing to do is divide the
meeting between past (cleanup of RFC3530bis, v4.1 errata), and future,
50-50 or whatever makes sense and apply priorities within those two
classes.  We can have big fights about the ratio, even after we agree
that there is a ratio.

I think we need to make progress on both divisions (I'm calling them
Archaea and Eukarya :-).  I think the most important thing in making the
meeting productive is to have clear material written in advance laying
out the issues and alternatives.  There will be some measure of "you've
got it all wrong" at the meeting but that beats trying to synthesize a
set of issues in the meeting.  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.
First dibs on the kingdom/phylum name Euryarchaeota :-) 

-----Original Message-----
From: nfsv4-bounces <at> ietf.org [mailto:nfsv4-bounces <at> ietf.org] On Behalf
Of Spencer Shepler
Sent: Monday, December 06, 2010 1:54 PM
(Continue reading)

sfaibish | 6 Dec 2010 21:10

Re: Determining interrim meeting interest

I would suggest to have the continuation of the discussions at
the BAT as they were related to both errata's and new stuff. I
will put together the list of issues that we left unfinished
at BAT soon.

/Sorin

On Mon, 06 Dec 2010 14:33:01 -0500, <david.noveck <at> emc.com> wrote:

> I agree with Spencer.  There is no reason to exclude these errata (or
> possible errata) from the list.  The question is what is the proper
> priority ordering of the list if we find out that there is more to
> discuss than time.
>
> It is troubling that we have these uncertainties that are creating
> difficulties for implementation.  To me that makes the priority higher.
>
> I can see Tom's concern that there is v4.2 stuff that does need to get
> some progress made, despite the high priority for clearing up the pNFS
> (and other such?) stuff.  Maybe the right thing to do is divide the
> meeting between past (cleanup of RFC3530bis, v4.1 errata), and future,
> 50-50 or whatever makes sense and apply priorities within those two
> classes.  We can have big fights about the ratio, even after we agree
> that there is a ratio.
>
> I think we need to make progress on both divisions (I'm calling them
> Archaea and Eukarya :-).  I think the most important thing in making the
> meeting productive is to have clear material written in advance laying
> out the issues and alternatives.  There will be some measure of "you've
> got it all wrong" at the meeting but that beats trying to synthesize a
(Continue reading)

Fred Isaman | 6 Dec 2010 22:33
Picon
Favicon

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
(Continue reading)


Gmane