Subject: [nfsv4] 5664bis review comments

From: <[email-masked]>
Date: Thu, 26 Apr 2012 10:26:33 -0400

1. -----------------

Document would be helped by an overview of the changes from
RFC5664.

Something else that might best be done here is some discussion of
a general framework for changes/additions beyond 5664bis.  In a number
of places (e.g versions, raid algorithms) there are references to things
that will/may be added in the future.  It seems we need some general
framework for a discussion of minor/micro/nano-versioining issues for 
the object mapping type.

3.2 ----------------

"object-based layout- supported" is wrong but I don't think
tinkering with the spaces and hyphens is the answer.  Suggest 
rewriting the sentence as:
   
    Some of the  RAID algorithms supported by object-based
    layouts encode redundant information and can compensate
    for missing components, but the data placement algorithms 
    need to be aware of the logical positions of the missing 
    components.

As regards the version, what is written there is confusing to me.

Part of the problem is in the "seems most robust" thing.  It leads to 
the question "Well, is it really most robust?" and then you're in a real 
swamp.  It might be better to say "That's what we've chosen. Deal 
with it."

Another issue is that you are pointing at two possible sources of what 
should be the same information and if you do that you have to tell
people what to do if they give different answers.

It may be that you are just stuck here while you are predicting the 
future regarding the (anticipated) v2.

I suggest dropping PNFSD_OSD_VERSION_2 for now and saying that additional 
values of pnfs_osd_version4 may be used to indicate the availability of 
additional features such as those proposed for the anticipated 
version 2.0 of the standard.

5.4 ----------------------------

As far as non-raid-0, what seems to be missing is some statement of 
what exactly the client's responsibilities are regarding updating the
redundant data.  While it seem obvious that if you change the data, 
you *need to* (just to avoid the SHOULD/MUST conundrum) update the
parity, you need some clarity on exactly when.  Now normally I'd assume 
that if you are returning a layout you are certifying that those
updates have been done.  But that may run into a conflict with the fact
that you have to return a layout if you get an io error. (or maybe it
doesn't -- I'm not sure).

A related issue concerns client  reboot which may make it impossible to
complete the updates.  Saying "The client MUST NOT reboot" (not that
I'm proposing that) poses implementabiliity issues :-)

Along the same lines, when the metadata server grants such a read
layout, is he certifying that the parity is correct and may the client 
rely on that?

Similar considerations apply to layouts with mirroring so maybe all
such issues should be dealt with in a common section.

5.4.1 ------------------------

Second sentence is not clear.  Also, it isn't clear to me that 
"MUST" is appropriate regarding the interface between the pNFS
client and the application.  Suggest:

   If a component is marked as PNFS_OSD_MISSING and a read is done
   from this component, the client MUST obtain the data from the 
   pNFS server, if such data is to be read at all.

5.4.5 -------------------------

The first paragraph belongs either in the front of the raid section 
or in a common section that includes mirroring issues.

The second paragraph should not go into so much detail on raid algorithms 
but deal more with the compatibility issues involved in introducing 
additional raid types.

7. -----------------------------

Need more clarity about any promptness requirements about LAYOUTRETURN in
the event of errors (and if there aren't any this should be explicit).

In second paragraph "The metadata server analyzes .." should be replaced 
by "The metadata server is responsible for analyzing ...'

In the third paragraph, the referent of "these cases" isn't clear.

Some issues in the fourth paragraph:

   "MAY be acceptable' is unclear.  Note that "MAY" means "is 
   acceptable" So "may be acceptable" seems like "possible risk" 
   (as opposed to "actual risk") re cellphones.  But what does 
   "MAY be acceptable" mean?

   Moving to the substance, it is clear that you are talking about 
   writes here and that if some part of the write have been done,
   just dropping other parts and saying "forget it" is not very
   acceptable.  So maybe "MAY be acceptable" should be replaced
   by "will be acceptable under certain circumstances." (if you 
   specify those circumstances).

   While it is clear that the client needs to either do the IO
   to the server or go through the recovery and get a new layout, 
   there should be a "MUST" saying this.  Also it isn't clear 
   which of the SHOULD's in this paragraph need to be capitalized 
   and why.

---

From: "Welch, Brent" <[email-masked]>
Date: Fri, 27 Apr 2012 01:12:16 +0000

Thanks for the detailed reviews.  We'll huddle and work on updated text to address your excellent points.

--
Brent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, April 26, 2012 7:27 AM
To: [email-masked]
Subject: [nfsv4] 5664bis review comments

1. -----------------

3.2 ----------------

   While it is clear that the client needs to either do the IO
   to the server or go through the recovery and get a new layout, 
   there should be a "MUST" saying this.  Also it isn't clear 
   which of the SHOULD's in this paragraph need to be capitalized 
   and why. 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4