Subject: [nfsv4] moving draft-ietf-nfsv4-rfc5664bis-01 forward

From: Spencer Shepler <[email-masked]>
Date: Thu, 19 Apr 2012 16:45:19 +0000

At this point, as document shepherd, I am uncomfortable with moving this
document forward within the IETF.  I don't it has received sufficient
review by the working group even though we have completed last call.

If you have reviewed this document, please let me know.
If you plan to review it, let me know when that review will be complete.

Thanks,
Spencer

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 19 Apr 2012 17:23:31 +0000

I've reviewed the document before it was promoted to a WG item.

I can have another round of reviewing done by 4/27/12.

On 4/19/12 11:45 AM, "Spencer Shepler" <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Thu, 19 Apr 2012 14:05:43 -0400

I'll get you some comments in the next two weeks. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Shepler
Sent: Thursday, April 19, 2012 12:45 PM
To: [email-masked]
Subject: [nfsv4] moving draft-ietf-nfsv4-rfc5664bis-01 forward

Thanks,
Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 19 Apr 2012 18:16:47 +0000

Thanks, Dave and Tom.  I will hold the document until the first week of May.

Additional reviews would be appreciated (needed), so let me know.

Spencer

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, April 19, 2012 11:06 AM
> To: Spencer Shepler; [email-masked]
> Subject: RE: moving draft-ietf-nfsv4-rfc5664bis-01 forward
>

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 23 Apr 2012 23:57:34 +0000

My biggest problem with this draft is that the Data Mapping Schemes are
presented for RAID0 without first detailing that fact.

When we get to the calculations for the higher RAID configurations, no
examples are provided to illustrate the changes needed.

I think the authors are too close to the problem.

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

5.3.2.  Nested Striping

   W: stripe width
     W = group_width, if not zero, else FW
^^ If what is not zero?

   D: number of data devices in a stripe
     D = W
^^ Why an alias? You might point out this will change when you add parity?

Yet in the example,

   For example, consider an object striped over 100 devices with a
   group_width of 10,

   Offset 0:
   W = 100
   group_count = 100 / 10 = 10
   D = 10

10 != 100

Actually, W may be off here.

-----------

5.4.2.  PNFS_OSD_RAID_4

   P: number of parity devices in each stripe
     P = 1

So P is always 1?

------

5.4.3.  PNFS_OSD_RAID_5

   Note that the math for RAID_5 is similar to RAID_4 only that the
   device indices for each stripe are rotated backwards.  So start with
   the equations above for RAID_4, then compute the rotation as
   described below.  Also note that the parity rotation cycle always
   starts on group boundaries so the first stripe in a group has its
   parity at device D.

Which equations above for RAID_4? Use section numbers.

The parity is always at device D if one uses the convention that the first
device is always 0.

   P: number of parity devices in each stripe
      P = 1

   PC: Parity Cycle
       PC = W

   R: The parity rotation index
      (N is as computed in above equations for RAID-4)
      R = N % PC

   I: parity device index
      I = (W + W - (R + 1) * P) % W

Shouldn't this be Ir?

   Cr: The rotated device index
       (C is as computed in the above equations for RAID-4)
       Cr = (W + C - (R * P)) % W

   Note: W is added above to avoid negative numbers modulo math.

The Note doesn't follow. Is it for both I and Cr?

I'm not really seeing the motivation for doing these equations. Where does
Cr get used?

Cr replaces C in the respective 5.3.1 and 5.3.2?

Perhaps some examples?

Both of t

-----

5.4.4.  PNFS_OSD_RAID_PQ

   with XOR.  The Q computation is described in detail by Anvin [20].

Should be:

   with XOR.  The Q computation is described in detail in [20].

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

   [20]  Anvin, H., "The Mathematics of RAID-6", May 2009,
         <http://kernel.org/pub/linux/kernel/people/hpa/raid6.pdf>.

Is this a stable enough source?

   [21]  The free encyclopedia, Wikipedia., "Least common multiple",
         April 2011,
         <http://en.wikipedia.org/wiki/Least_common_multiple>.

Really, quoting Wikipedia? Either LCM is well understood or quote
something that doesn't change on the whim of some random contributor.

   [22]  Plank, James S., and Luo, Jianqiang and Schuman, Catherine D.
         and Xu, Lihao and Wilcox-O'Hearn, Zooko, "A Performance
         Evaluation and Examination of Open-source Erasure Coding
         Libraries for Storage", 2007.

How about:

   [22]  Plank, J. S., Luo, J. and Schuman, C. D., Xu, L. and
Wilcox-O'Hearn, Z., "A Performance
         Evaluation and Examination of Open-source Erasure Coding
Libraries for Storage", 2007.