Subject: Re: [nfsv4] Layout Structures Improvement

From: "Anatoly Pinchuk" <[email-masked]>
Date: Thu, 13 Mar 2008 16:07:28 -0700

First of all I suggest that we focus on the technical and logical part
of the discussion. So, I am not going to comment on your notes about
people (their issues, doings, disappointments ...) and your suspicions.
It is all irrelevant. Also, to avoid repetition, I am not going to
comment on well-known events that have happened in this thread, and your
opinion about these events. And finally, since I agree with you, I will
not address the fragment you characterized as "Not that it matters". Not
much left after that.

1. Sentence removal proposal with no reply.
Once more, there was no reply. One can check IETF mail archive. If you
did something about this proposal, it does not invalidate the fact -
there was no reply and suggestion was incorporated into the protocol.

2. 
> I don't know what you are referring to. What over the network change
> to the files layout did I change in Dec 2007?
In Dec of 2007 I provided simplification of the client file offset
translation solution as requested at the meeting in Vancouver. The
solution itself was proposed even earlier. You decided to incorporate
just part of that simplified solution into the protocol, namely added
nfl_pattern_offset to nfsv4_1_file_layout4 structure. That was the a
network change. At that time you had a chance to accept the whole change
and solve all the problems at once. The network change was done anyway.

In conclusion I suggest that we keep the discussion productive and avoid
going over the same topics again and again. Also discussing
problems/solutions, but not the people might help to improve the quality
of the discussion. This is the link to the solution benefits
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05536.html
If you find some NEW potential problem with the proposal itself or its
adoption, let me know. Note that I have already addressed all the
problems/concerns people had. That includes
- misunderstanding of the proposal
- change makes just some messages shorter
- change is good but not good enough
- nobody replied to the proposal
- nobody supports the proposal
- safety of the change
- ... see thread

- Anatoly

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

To: nfsv4 at ietf.org 
Subject: Re: [nfsv4] Layout Structures Improvement 
From: "Mike Eisler" <mre-ietf at eisler.com> 
Date: Wed, 12 Mar 2008 19:37:29 -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: <A062FCC8662DA848949F7C3046B9BEAEB94B38 at
us-email.terastack.bluearc.com> 
Sender: nfsv4-bounces at ietf.org 
User-agent: SquirrelMail/1.4.10a 

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

> 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.

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.

> Conclusion - lack of the replies (consensus) generally does not
prevent
> us from accepting the proposal.

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

>
>> 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

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 nfsv4 at ietf.org 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?

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

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

References: 
Re: [nfsv4] Layout Structures Improvement 
From: Anatoly Pinchuk
Prev by Date: Re: [nfsv4] Layout Structures Improvement 
Next by Date: Re: [nfsv4] cb_sequence referring calls list usage 
Previous by thread: Re: [nfsv4] Layout Structures Improvement 
Next by thread: [nfsv4] Pending changse for spec 
Index(es): 
Date 
Thread
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Benny Halevy <[email-masked]>
Date: Fri, 14 Mar 2008 10:14:34 +0200

> going over the same topics again and again. Also discussing

Anatoly, first I'd like to say that I admire your persistence!
But you have to face it that your proposal was, in effect, rejected.
Unless you come up with *new* technical issues that justify
your proposal and, in particular, they need to show that the current
scheme is *broken*, not just inferior to yours, I see no way that
we can make progress.

Benny

> Delivered-to: ietfarch-nfsv4-web-archive at core3.amsl.com 
> Delivered-to: nfsv4 at core3.amsl.com 
> In-reply-to: <A062FCC8662DA848949F7C3046B9BEAEB94B38 at

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Fri, 14 Mar 2008 16:20:13 -0700

As for the persistence, I just comply with the major requirement for a
storage system. :)

> scheme is *broken*, not just inferior to yours, I see no way that
My goal from the very beginning was pure technical - provide the
protocol improvement in measurable terms and enough additional
information (explanation, reasoning ...), so WG can make informative
decision according to appropriate procedures. It turned out that
significant time was taken debating justifications for not accepting the
proposal which I found incorrect. 
In particular, I noted that fixing something which is broken in the
protocol is not a mandatory requirement for incorporating an improvement
into the protocol. We have changes incorporated into the protocol which
do not fix something that is broken; they just improve the logic,
clarify semantics, and/or change wording and so on. As for the progress,
it is up to the WG.
I am not trying to force people opinions, just provide necessary
information.

- Anatoly

> -----Original Message-----
> From: Benny Halevy [mailto:[email-masked]]
> Sent: Friday, March 14, 2008 1:15 AM
> To: Anatoly Pinchuk
> Cc: [email-masked]