Subject: Re: [nfsv4] File Layout change proposal

From: "Anatoly Pinchuk" <[email-masked]>
Date: Wed, 13 Feb 2008 18:28:46 -0800

Back in December we fixed the client offset translation problem for the
file layout type. It was done by adding 'offset4 nfl_pattern_offset'
into nfsv4_1_file_layout4 structure and replacing 'layout4 logr_layout'
with 'layout4 logr_layout<>' in LAYOUTGET4resok one.

That was simple solution but it brought unnecessary overhead and
complication into the protocol. I think it is time to resolve the
remaining issues before they become a standard. The solution is easy and
well known - to base file (not generic) layout on array of the segments.
Below is a list of some existing downsides we might want to fix.

In order to fix the file layout type specific problem the generic
structure LAYOUTGET4resok was changed. That change broke simple
LAYOUTGET semantic which existed in draft 15 - a client request layout
for a range, the server returns layout for a sub-range. Layout has only
one type and one IO mode. Now the client gets array of sub-layouts
(ranges, IO modes, types). Also there are dependencies between the
sub-layouts. In reality, the change can and should be done at file
layout level without disturbing generic LAYOUTGET semantic.

Unnecessary field duplications can lead to rather long result of
LAYOUTGET. For example, N * (sizeof(offset4) + sizeof(length4) +
sizeof(layoutiomode4) + sizeof(layouttype4) + sizeof(offset4)) bytes are
needed to carry result offsets, lengths, IO modes, and layout types,
where N is a number of the layout4 structures in LAYOUTGET4resok. With
the fix we have the same information can be passed using just
sizeof(offset4) + sizeof(length4) + sizeof(layoutiomode4) +
sizeof(layouttype4) + N * sizeof(offset4) bytes. In particular, such
difference in length could be important since the client controls length
of the result with loga_maxcount field.

The field duplication above complicates the protocol and, therefore,
client and server implementation. Such sentences as "Each element of
logr_layout MUST have the same iomode" will not be needed if we
structure result of LAYOUTGET right (just one iomode field). It is also
not obvious why the protocol defines several LAYOUTGET fields with the
same value guaranteed.

- Anatoly

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

---

From: Robert Gordon <[email-masked]>
Date: Wed, 13 Feb 2008 20:58:51 -0600

Does this dot-x file diff represent the proposed change ?

--- d19-nfsv41.x        2008-02-12 16:16:49.000000000 -0600
+++ d19-nfsv41-anatoly.x        2008-02-13 20:56:47.000000000 -0600
@@ -522,7 +522,7 @@
          offset4                 lo_offset;
          length4                 lo_length;
          layoutiomode4           lo_iomode;
-        layout_content4         lo_content;
+        layout_content4         lo_content<>;
  };

  const NFS4_DEVICEID4_SIZE = 16;
@@ -2317,7 +2317,7 @@
  struct LAYOUTGET4resok {
          bool               logr_return_on_close;
          stateid4           logr_stateid;
-        layout4            logr_layout<>;
+        layout4            logr_layout;
  };

-- 
Robert...
"Procrastination is the thief of time"

---

From: Mike Eisler <[email-masked]>
Date: Wed, 13 Feb 2008 20:33:08 -0800 (PST)

> Below is a list of some existing downsides we might want to fix.

The downside of your proposal is that there is no layout-type
independent way to allow a file to have two different striping
patterns.

At any rate, the editors believe there was a rough consensus
to go with the solution in draft-18 and -19.

And we trying to get done.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 13 Feb 2008 20:36:22 -0800 (PST)

That reverses a change that was done in order to allow a file
to have two different striping patterns.

The file system my pNFS server uses requires two different striping
patterns for two different, non-overlapping, ranges of the file.

I admit there is more optimal way to cast the data structures
(without driving the logic into the files layout type).

Do people want the spec to stabilize or not?

---

From: Robert Gordon <[email-masked]>
Date: Wed, 13 Feb 2008 22:44:44 -0600

I was attempting to understand in a dot-x manor, the proposed
change.. and then say "let's keep what we have"

> Do people want the spec to stabilize or not?

Heck yes :-)

Robert.

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Wed, 13 Feb 2008 23:01:15 -0800

The file does not represent the changes. Please see
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05174.html
for the proposed solution.

-Anatoly

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Thu, 14 Feb 2008 00:29:17 -0800

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.

- Anatoly

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 14 Feb 2008 09:08:03 -0600

> 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