Subject: Re: [nfsv4] Layout Structures Improvement

From: "Anatoly Pinchuk" <[email-masked]>
Date: Wed, 12 Mar 2008 19:02:46 -0700

The bottom line is that I proposed the change (you can provide a link if
somebody else did it earlier) and the change was incorporated into the
protocol. At the same time, there was no single reply to the proposal.
Conclusion - lack of the replies (consensus) generally does not prevent
us from accepting the proposal.

> The bar for an over the network change, which is what you've
> been demanding for months, during a WG last call,
> is much higher though. Every time we've changed the
> files layout structures, new errors have been introduced. I
> don't want to take that risk right now, so I'm unwilling to state I
agree
> with your proposal.
In our case risk is lower than usually since, as you noted, I proposed
the change several months ago. So, the WG had enough time to validate
it. Also I did my best to minimize number over the network change. It
all could be done in Dec of 2007 when you made network change anyway.

- Anatoly

------------------------------------------------------------------------
-

To: nfsv4 at ietf.org 
Subject: Re: [nfsv4] Layout Structures Improvement 
From: "Mike Eisler" <mre-ietf at eisler.com> 
Date: Tue, 11 Mar 2008 17:14:42 -0700 (PDT) 
us-email.terastack.bluearc.com > 
List-archive: <http://www.ietf.org/pipermail/nfsv4> 
List-help: <mailto:[email-masked]?subject=help> 
List-id: NFSv4 Working Group <nfsv4.ietf.org> 
List-post: <mailto:[email-masked]> 
List-subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
<mailto:[email-masked]?subject=subscribe> 
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
<mailto:[email-masked]?subject=unsubscribe> 
References: <A062FCC8662DA848949F7C3046B9BEAEB942A4 at
us-email.terastack.bluearc.com> <274184.8736.qm at
web38104.mail.mud.yahoo.com> <A062FCC8662DA848949F7C3046B9BEAEB945B4 at
us-email.terastack.bluearc.com> 
Sender: nfsv4-bounces at ietf.org 
User-agent: SquirrelMail/1.4.10a 

------------------------------------------------------------------------
--------

> As for examples of demonstration of rough consensus, I can add one
too.
> Unless I missed a reply supporting the change, rough consensus on my
> proposal
> http://www.ietf.org/mail-archive/web/nfsv4/current/msg05507.html has
> been demonstrated without single additional proponent for making the
> change.

http://www.ietf.org/mail-archive/web/nfsv4/current/msg05507.html is
reproduced below after the bar containing equal (=) signs.
I  believe you are refering to threse snippets of conversation on the
nfsv4 at ietf.org list which are in the message you reference.

Anatoly Pinchuk (AP):

    Let us take an example from section 18.43.3.

    "The lo_length field in each element of logr_layout SHOULD be at
     least
     as long as loga_minlength or the server SHOULD reject the request."

Mike Eisler (ME):

     One thing I'm not sure of is what error the server should reject
     the request with.

AP:

     The sentence should be removed from the protocol at all,
     since it justifies a server implementation rejecting
     LAYOUTGET which could be processed.

----------------------------------------------

So you are stating that because sentence apparently no
longer appears in the specification without anyone
(apparently) agreeing with you, this is
an example of a decision being made without
a rough consensus.

It turns out that while that sentence is gone from that part
of a text for good reason, because another place in draft-20 the
spec said:

  The loga_minlength field specifies the minimum length of layout the
  server MUST return. If this requirement cannot be met, no layout
  must be returned; the error NFS4ERR_BADLAYOUT will be returned.

So this text both addressed your issue, and it also addressed my issue
which was what error should be returned. However it was in conflict
with the sentence you said should be deleted.

A second however was that the above text was worded very badly, and
a third was that it did not handle the situation of EOF (as pointed out
by
Jason Glasgow in
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05548.html ).

In that thread I also noted that it didn't deal with the case of a range
that overlapped multiple striping patterns.

What we ended up with can be seen in the diffs that were posted to
that thread, or look at:

"The loga_minlength field specifies the minimum length of layout the
 server MUST return with two exceptions:

1. The argument loga_iomode was set to LAYOUTIOMODE_READ, and
   loga_offset plus loga_minlength goes
   past the end of the file.

2. The range from loga_offset through loga_offset + loga_minlength -
   1 overlaps two or more striping patterns. In which case,
   logr_layout will contain two or more elements, and the sum of the
   lo_length fields of each element MUST be at least loga_minlength
   unless the first exception also applies.

If this requirement cannot be met, the server MUST NOT return a
layout and the error NFS4ERR_BADLAYOUT MUST be returned.

''

As an editor and document author, I often have to propose text
to address things at least one other person finds (for example,
I wrote the RPCSEC_GSS version 2 i-d based on the proposal of
a single person, and was authorized by the co-chairs to
publish it as a work item of this WG). If it is just
one other person, and I agree with the core of what person finds, then
I see a consensus that I am member of, and I make those changes.
(If the WG chairs want me to act differently, they can tell me.)

But in the case you are claiming as a counter example, three
people, you, Jason, and me, agreed that what was there was wrong,
and so it was changed. So an even wider consensus was reached.

The bar for an over the network change, which is what you've
been demanding for months, during a WG last call,
is much higher though. Every time we've changed the
files layout structures, new errors have been introduced. I
don't want to take that risk right now, so I'm unwilling to state I
agree
with your proposal.

And no one else is has so far been willing
to state agreement to your proposal.
So no change.

=========================================================

To: <nfsv4 at ietf.org>
Subject: Re: [nfsv4] File Layout change proposal
From: "Anatoly Pinchuk" <apinchuk at bluearc.com>
Date: Thu, 14 Feb 2008 13:19:34 -0800

------------------------------------------------------------------------
--------
The sentence should be removed from the protocol at all, since it
justifies a server implementation rejecting LAYOUTGET which could be
processed.

- Anatoly

To: nfsv4 at ietf.org
Subject: Re: [nfsv4] File Layout change proposal
From: Mike Eisler <email2mre-ietf at yahoo.com>
Date: Thu, 14 Feb 2008 12:03:44 -0800 (PST)

--- Anatoly Pinchuk <apinchuk at bluearc.com> wrote:

>  Apparently, it is
> up
> to the editors to decide if there is enough time to fix the problem.

It's up to the working group to decide if there is problem, if so, is
it
worth fixing, and if so, what we should do.

I haven't seen any other contributor to this working group support
your proposal.

> Let us take an example from section
> 18.43.3.
>
> "The lo_length field in each element of logr_layout SHOULD be at
> least
> as long as loga_minlength or the server SHOULD reject the request."

One thing I'm not sure of is what error the server should reject
the request with.

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

------------------------------------------------------------------------
--------

References: 
Re: [nfsv4] Layout Structures Improvement 
From: Anatoly Pinchuk
Re: [nfsv4] Layout Structures Improvement 
From: Mike Eisler
Re: [nfsv4] Layout Structures Improvement 
From: Anatoly Pinchuk
Prev by Date: Re: [nfsv4] Layout Structures Improvement 
Next by Date: Re: [nfsv4] Layout Structures Improvement 
Previous by thread: Re: [nfsv4] Layout Structures Improvement 
Next by thread: Re: [nfsv4] Layout Structures Improvement 
Index(es): 
Date 
Thread
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 12 Mar 2008 19:37:29 -0700 (PDT)

> protocol. At the same time, there was no single reply to the proposal.

One person (me) immediately replied. And Jason Glasgow
started a new thread that indirectly supported your proposal
because it pointed out that the sentence you wanted deleted conflict
with other text in the specification. Other text that others were
already following in their implementations.

So rough consensus existed. If in your world rough consensus has to
be direct reply to what you write, then life, or at least this
working group is going is to continue to disappoint.

> us from accepting the proposal.

Conclusion: you apparently think that if I agree with you on something,
it isn't a consensus.

> the change several months ago. So, the WG had enough time to validate

And no one agreed with you.

You may think people agree with you. You may even have
people emailing you, phoning you, commiserating with you, etc.
But they aren't saying anything on [email-masked] in support of you,
or at IETF meetings.

Not one.

Instead at least two people replied and said to effect: "no, I
do not want to change it". But still you profess there is a
consensus that supports you:

``The fact is that I have not convinced several people which stated it
clearly. As for anyone, it is an opinion.''

> it. Also I did my best to minimize number over the network change. It

You could have done much better by the way. Not that it matters, but

-struct nfsv4_1_file_layout4 {
-         deviceid4      nfl_deviceid;
-         nfl_util4      nfl_util;
-         uint32_t       nfl_first_stripe_index;
-         offset4        nfl_pattern_offset;
-         nfs_fh4        nfl_fh_list<>;

+struct nfsv4_1_file_layout_segment4 {
+         offset4        nfls_off;
+         deviceid4      nfls_deviceid;
+         nfl_util4      nfls_util;
+         uint32_t       nfls_first_stripe_index;
+         nfs_fh4        nfls_fh_list<>;

rearranged most of the data structure. What was wrong with,

+struct nfsv4_1_file_layout_segment4 {
+         deviceid4      nfls_deviceid;
+         nfl_util4      nfls_util;
+         uint32_t       nfls_first_stripe_index;
+         offset4        nfls_pattern_offset;
+         nfs_fh4        nfls_fh_list<>;

?

You seemed have more issues with what is in the
current spec than just whether the array is in the
files-specific layout than in the generic layout.
Order of fields and the name of the suffix of one of the fields.

Which I suspect made many people think your proposal was mostly about
your subjective view of what was in good taste or not. Perhaps
some people saw little need to re-write an encoder and decoder
to satisfy what they saw as your whim, on a data structure that
has churned too much since the 2007 Austin bake-a-thon.

> all could be done in Dec of 2007 when you made network change anyway.

I don't know what you are referring to. What over the network change
to the files layout did I change in Dec 2007?