Re: [nfsv4] What does v4.2 look like?

[<[e-mail]>]

> Without a clear picture of what v4.2 means, is this the type of thing
we 
> want to put in it? 

Without a clear picture of what v4.2 means, how could I answer that? :-)

Clearly, I've made a mistake.  Let me change:

    and I think some v4.2 changes would be required

To

    and I think some changes in v4.2 or a subsequent minor version 
    would be required

There seems to be an inconsistency between saying we couldn't do this
because we don't have a clear picture of what v4.2 means, and then also
saying we couldn't do this because we do have a clear picture and this
doesn't fit.  Right now it doesn't fit because there is no substantive
proposal to address it.  I was just saying I didn't see how that issue
could be addressed in v4.1 but I could be wrong about that.

As to the things that have been proposed, I think your characterization
is accurate, but I don't see that it should be controlling.  If we had a
large change that was inconsistent with dealing other things that were
in in a reasonable time, that would be a reason to exclude it, but if
you have a bunch of small features adding ops, then putting in an op to
correct an issue we found doesn't seem so discordant.  After all, Bruce
might argue that this is the "cross-session request EOS" feature and he
would not necessarily be wrong.  For a lot of things, the line between
correction and feature isn't so clear. 

> I don't see it as fixing things we got subtly wrong in either 4.0 or
4.1. 

If not, would we have a whole minor version devoted to fixing things we
got subtly wrong in earlier minor versions?  Fixing such things is
something that people recognize should be done but it just won't hold
the group's interest for an entire minor version (and that of
implementers and of executives allocating their time to work on clients
and servers).  It has to be combined with other things and the simplest
model is to do them as soon as someone has a clear solution that people
agree makes things better.  That may not be v4.2 for this issue but if
someone does have a reasonable way of addressing it, I don't see why it
should be excluded.

> when does it make
> sense to have one document to consult versus 10 other ones?

The first answer is "not for v4.2" and I haven't heard anybody disagree
about that.

But you are right that if v4.x gets a lot higher this will be an issue.

I think it is clear we will never have a document bigger than 650 pages.

We'll need, at that point, not one document but a set of documents, not
organized by version but organized by topic.

At some point there will be a need for RFC5661bis and I think we should
make a big step in that direction, at that point.  So we might have,

    An introductory document containing basically chapters 1-4, 14, 16,
17, 19, 21, 22.
    A file attributes document containing chapters 5-6.
    A namespace document containing chapters 7 and 11.
    A locking document containing chapters 8-10.
    A pNFS document containing chapters 12 and 13.

Those document would be written so that covered all versions (except
v4.0).  Most of them would not have to be updated for a minor version.
You could then periodically write a new document that covered the
material in chapters 15, 18, 20, as updated for the current minor
version.  Alternatively, that document could be smaller, only containing
chapter 15 and an index of where to go for the current handling of each
op and callback.  In terms of using a web version of the document, there
wouldn't be much difference between a link within a document and one
between documents.  As long as you go to the right place, the fact that
many documents are referenced should not matter.  

The big issue with doing like this is that it is a lot of editing work,
so I think the x in v4.x will have get fairly high before people decide
they have to take the issue on.





-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Tom Haynes
Sent: Tuesday, July 20, 2010 11:24 AM
Cc: [e-mail]
Subject: [nfsv4] What does v4.2 look like?

On 7/19/10 8:06 PM, [e-mail] wrote:
>
> Note that this doesn't fully address the issue of EOS across sessions
> for non-idempotent requests and I think some v4.2 changes would be
> required, but v4.1 does allow different so_minor_id value for
clustered
> servers, and it seems kind of rough to say you can only do this if you
> accept the possibility of data corruption.
>
>    

Without a clear picture of what v4.2 means, is this the type of thing we

want to put in it?

I'm not asking if it is something we want to fix, but rather is v4.2 the

right vehicle?

If I look at v4.2, I see it as a collection of small optional feature 
sets - pathless objects,
hole punching, space reservation, server to server copy, dedup, 
metastripe, access
check, etc. I could be wrong, but that seems to be what people are 
proposing.

I don't see it as fixing things we got subtly wrong in either 4.0 or
4.1.

Perhaps even releases introduce new functionality and odd releases are 
informational?
Even ones driven by design and odd ones driven by implementation
experience?

And that raises another question, according to your slide deck:
http://www.ietf.org/proceedings/10mar/slides/nfsv4-9.pdf

We don't want another huge document. But at what point do we want a 
comprehensive
document that rolls up all of the smaller v4.x changes from v4.1? I.e., 
when does it make
sense to have one document to consult versus 10 other ones?
_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4