Subject: Re: [nfsv4] File Layout change proposal

From: "Anatoly Pinchuk" <[email-masked]>
Date: Thu, 14 Feb 2008 12:59:41 -0800

I was never agreed with the current layout structures. That reflected in

http://www.ietf.org/mail-archive/web/nfsv4/current/msg05176.html
posting.
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05175.html reply
suggested postponing final solution until 2008. So, there was no reason
to bombard the working group with already well known solution earlier.
Also there was discussion on my proposal, the links above confirm that.
As result of that discussion field 'offset4 nfl_pattern_offset' was
added into nfsv4_1_file_layout4 structure. Nobody questioned the
correctness of the solution.

I have already provided suggestion for fixing the file layout related
problems. In particular, it will fix lo_length related one as well. The
sentence I mentioned will be gone, not re-phrased.

As for the WG convincing, I am working on it by posting the messages and
explaining the problems. I hope that there will be a feedback.

- Anatoly

On Feb 14, 2008, at 1:40 PM, Anatoly Pinchuk wrote:

> The posting I did is part of a review process to guarantee high 

> quality of the protocol. Its purpose is to bring to the working group 

> attention that there are many inconsistencies in common and file 

> layout definitions which complicate the protocol. It looks like we all

> agree on that. Another part of it is to remind that we have simple 

> solution of the problem proposed back in December.

2.5 months in relation to how much has changed in this specific area is
a very long time.  I had assumed that given your silence on this issue
to this point was an indication of consensus on the discussions and
email that occurred in December and the contents of draft-18.

That is now clearly not the case.

> A conclusion on if the layout inconsistencies we have are significant 

> and broke the protocol features is subjective. I think that current 

> layout definitions breaks (common layout) - (particular layout) 

> layering and unnecessary complicates the protocol/implementation. 

> Since there is simple solution, the definitions should be changed. 

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

> to fix the problem. I consider my part of the job is done.

With my editor hat on for a moment, our job is to work the internet
draft to closure without overly burdening the feedback and comments
unduly.  If rough consensus existed for modifications then it would be
considered appropriately.  At this point, I have seen but one advocate
(you) for the need for change.  If you feel that the something is broken
then it is your burden to convince others within the working group of
your position and the need for change.  All I have seen is a reference
to a posting from December without any discussion.

>  Also it is not obvious if a protocol feature is broken or burdens an 

> implementation significantly. 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."

> Because it says SHOULD the server can just ignore the above. On the 

> other hand it sounds like recommendation and some server 

> implementations may actually follow it. That will result in rejection 

> of the requests which could be successfully processed (if the 

> loga_minlength is greater than length of a sub-layout element of 

> logr_layout).

If you have suggestions for changes to the wording that will lead to a
better protocol definition and higher probability of interoperability,
then please make them.

In this particular case, the definition of SHOULD requires the server to
behave in the way stated unless it is a significant burden on the server
not to do so.  If you can make a case for a change to MUST, then again,
please do so.

> One can decide if such protocol definition breaks a feature or burdens

> an implementation significantly. But it definitely brings down quality

> of the protocol and complicates the implementation.

> Other layouts inconsistencies are similar in nature.

> I feel that a congregation of industry leaders and experts should not 

> produce work that obviously compromises on quality.

As mentioned above, if you feel this way then it is your burden to
convince enough of the working group to become vocal in support of your
position such that it demonstrates rough consensus for a change.  At
this point, we have rough consensus for the I-D the way it is.

Spencer

> - Anatoly

> On Feb 14, 2008, at 2:29 AM, Anatoly Pinchuk wrote:

> > The solution solves the problem we had - inability to translate the 

> > client offset in case of FILE LAYOUT. It resolves the problem

> without

> > affecting different type of layouts and other complications I

> pointed

> > out. As for the downside you mentioned, the draft defines striping 

> > only for file layouts. So far, the striping does not belong to

> common

> > layout.

> > If you want to define striping for all possible layout types, it 

> > should be reflected in the draft.

> > The solution brings clarity into common and file layouts. It is

> simple

> > (one page to describe) and removes unnecessary repetitions. All

> of the

> > above makes the protocol easier to understand/implement and shorten 

> > result of LAYOUTGET. Therefore, the solution provides a step towards

> > the optimal spec stabilization.

> Nothing in what you have mentioned above or elsewhere (to my

> knowledge) states that the current definition is flawed in a way that 

> can not be implemented or burdens an implementation significantly.

> As with all things engineering related, there is almost always a 

> better way to accomplish a task.  However, as was stated quite some 

> time ago, unless a protocol feature is demonstrably broken, we will 

> not be changing it at this point.  We have 560+ pages of protocol 

> specification to ensure are of reasonable quality.

> Let's focus on getting the whole reviewed and corrected.

> Spencer

 

_______________________________________________
nfsv4 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 14 Feb 2008 16:04:05 -0600

On Feb 14, 2008, at 2:59 PM, Anatoly Pinchuk wrote:

> posting. http://www.ietf.org/mail-archive/web/nfsv4/current/ 
> msg05175.html reply suggested postponing final solution until 2008.  
> So, there was no reason to bombard the working group with already  
> well known solution earlier. Also there was discussion on my  
> proposal, the links above confirm that. As result of that  
> discussion field ‘offset4 nfl_pattern_offset’ was added into  
> nfsv4_1_file_layout4 structure. Nobody questioned the correctness  
> of the solution.

I would suggest that you post a new email thread with a diff
of your suggested changes against the current dot-x and
provide the motivation.  Not just a reference to the
original email thread.  If there is support, then WG members
can voice their feedback at that point and do so more effectively.

Spencer