Subject: [nfsv4] draft-ietf-nfsv4-migration-issues-02.txt

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 14 Mar 2013 05:37:27 +0000

3.  NFSv4.0 Implementation Experience

1)
   o  The filesystem is migrated from ABC to server XYZ.  When

How about

   o  The filesystem is migrated from server ABC to XYZ.  When

2) Remove:

      So far, so good.

3)

   o  fs_a1 migrates from server ABC to server XYZ along with its state.
      Now server XYZ also has a lease: {v1, "C-ABC", c.i}.

To

   o  Filesystem fs_a1 migrates from server ABC to server XYZ along with its state.
      Now server XYZ also has a lease: {v1, "C-ABC", c.i}.

OR, earlier on you could document the naming convention. But you have gone from "F"
being a filesystem to "fs_" being a filesystem.

4)

   that of multiple clientid4's with the same nfs_client_id4 value.  The
   protocol is currently designed and implemented assuming this can't
   happen.  We need to either prevent the situation from happening, or

Is this cannot or can not?

5)

   o  There are a set of clients C1 through Cn accessing servers S1
      through Sm.  Each server manages some significant number of
      filesystems with the filesystem count L being significantly
      greater than m.

Up until now, S? denoted a stateid.

6) Used before defined:

   with clients implementing uniform client-strings.  As a consequence,
   care must be taken to preserve interoperability between UCS-capable
   clients and servers that don't tolerate uniform client strings for

becomes

   with clients implementing uniform client-strings (UCS).  As a consequence,
   care must be taken to preserve interoperability between UCS-capable
   clients and servers that don't tolerate UCS for

the other point being use either the acronym or the expanded version, but not
both.

I'd like to see a Definitions section.

7) I also find that both non-uniform client strings and uniform client strings
are presented as if the reader already knows what they mean. Is it chicken and
egg? Do you have to motivate the problem before presenting approaches?

8)

3.1.  Implementation issues

   Note that the examples below reflect current experience which arises
   from clients implementing the recommendation to use different
   nfs_client_id4 id strings for different server addresses, i.e. using
   what is later referred to herein as the "non-uniform client-string
   approach"

Need a '.' at the end.

9)

t
      says, in the third bullet point regarding construction of the
      string (which we shall henceforth refer to as client-string-BP3):

         The string should be different for each server network address
         that the client accesses, rather than common to all server
         network addresses.

I skipped over that henceforth the first time I read that. How about
this:

t
      says, in the third bullet point regarding construction of the
      string:

      CLIENT-STRING-BP3

         The string should be different for each server network address
         that the client accesses, rather than common to all server
         network addresses.

That should help the reader see you are defining a term and make it
stick out when they see if later:

   The fact that the reason given in client-string-BP3 is not valid
   makes the existing "should" insupportable.  We can't either

vs

   The fact that the reason given in CLIENT-STRING-BP3 is not valid
   makes the existing "should" insupportable.  We can't either

10)

5.2.3.  Mixing Client-string Approaches

   o  The non-uniform client-string approach is used when accessing
      servers whose implementations make them incompatible with the
      uniform client-string approach

Missing "." at end.

11)

   o  A second purpose to be able to use knowledge of trunking
      relationships for better performance, etc

Missing "." at end.

12)

   Given that we don't want to confirm something that we are not sure we

"do not"

13)

      Note that the v4.0 spec requires the server to make sure that such
      value are very unlikely to be regenerated.  Given that it is
      already highly unlikely that the clientid XC is duplicated by
      distinct servers, the probability that Sc is duplicated as well
      has to be considered vanishingly small.  Note also that the

Should be "SC".

14)

6.  Results of proposed changes for NFSv4.0

   The purpose of this section is to examine the troubling results
   reported in Section 3.1.  We will look at the scenarios as they would
   be handled within the proposal.

   Because the choice of uniform vs. non-uniform nfs_client_id4 id
   strings is a "SHOULD" in these cases, we will designate clients that
   follow this recommendation by SHOULD-UF-CID.

   We will also have to take account of any merger-related "SHOULD"
   clauses to better understand how they have addressed the issues seen.
   We abbreviate as follows:

   o  SHOULD-SVR-AM refers to the server obeying the SHOULD which
      RECOMMENDS that they merge leases with identical nfs_client_id4 id
      strings and boot verifiers.

Get rid of the symbols and rewrite as:

6.  Results of proposed changes for NFSv4.0

   The purpose of this section is to examine the troubling results
   reported in Section 3.1.  We will look at the scenarios as they would
   be handled within the proposal.

   SHOULD-SVR-AM
      Refers to clients that follow the recommendation of "SHOULD" on
      the choice of uniform vs. non-uniform nfs_client_id4 id
      strings.

   We will also have to take account of any merger-related "SHOULD"
   clauses to better understand how they have addressed the issues seen.

   SHOULD-SVR-AM
      Refers to the server obeying the SHOULD which
      RECOMMENDS that they merge leases with identical nfs_client_id4 id
      strings and boot verifiers.

Not so hot on the hack I did in SHOULD-SVR-AM, but you can tighten that
up.

15)

6.1.  Results: Failure to free migrated state on client reboot

   Let's look at the troublesome situation cited in Section 3.1.1.  We
   have already seen what happens when SHOULD-UF-CID does not hold.  Now
   let's look at the situation in which SHOULD-UF-CID holds, whether
   SHOULD-SVR-AM is in effect or not.

with

6.1.  Results: Failure to free migrated state on client reboot

   The situation cited in Section 3.1.1 describes
   what happens when SHOULD-UF-CID does not hold.  Now
   let's look at the situation in which SHOULD-UF-CID holds, whether
   SHOULD-SVR-AM is in effect or not.

16)

Confused:

6.2.  Results: Server reboots resulting in confused lease situation

   not hold .  Now
   let's look at the situation in which SHOULD-UF-CID holds and SHOULD-
   SVR-AM holds as well.

(Fix space before '.')

....

and

   Now let's consider the same scenario in the situation in which
   SHOULD-UF-CID holds and SHOULD-SVR-AM holds as well.

The second implies the first has one of SHOULD-UF-CID or SHOULD-SVR-AM
not holding, but the first claims they both hold!

16)

   o  Client C reboots and attempts to access data on server XYZ,
      whether in filesystem F or another.  It does a SETCLIENTID with an
      nfs_client_id4 with id string value "C" and boot verifier 0x112.
      The state associated with lease {0x111, "C", C1} is deleted as
      part of creating {0x112, "C", C2}.  No problem.

has 0x112 for boot verifiers, C? for clientid.

   o  Client C talks to server ABC using an nfs_client_id4 id string
      such as "C-ABC" and boot verifier v1.  As a result a lease with
      clientid4 c.i established: {v1, "C-ABC", c.i}.

has v? for boot verifiers, c.? for clientid.

Adopt a consistent format.

17)

   o  fs_a2 migrates from server ABC to server XYZ.  As part of
      migration the incoming lease is seen to denote same Nfs_client_id4
      and so is merged with {v1, "C-ABC, c.i}.

should be "nfs_client_id4"

18)

   o  If we look at this in the SHOULD-UF-CID case in which the SHOULD-
      SVR_AM condition holds, the situation is no different.  Although
      the server has the client identity information that could enable
      same-client-same-server leases to be combined, it does not do so.
      We still have up to L clientid's per client.

   o  On the other hand, if we look at the SHOULD-UF-CID case in which
      SHOULD-SVR-AM holds, the problem is gone.  There can be no more
      than m clientids per client, and n clientid's per server.

What am I missing here? They both claim "SHOULD-SVR-AM" holds.

First one should be "SHOULD-SVR-AM" and not "SHOULD-SVR_AM".

19)

   The existing treatment of state transfer in [RFC5661], has similar
   problems to that in [RFC3530] in that it assumes that the state for
   multiple fs's on different servers will not be merged to so that it
   appears under a single common clientid.  We've already seen the
   reasons that this is a problem, with regard to NFSv4.0.

   Although we don't have the problems stemming from the non-uniform

"fs's" should be "filsystems" (saw this earlier as well).
"We've" should be "We have"
"don't" should be "do not"

20)

   o  Migration is currently treated together with other sorts of file
      system transitions including transitioning between replicas

Looks like "file system" instead of "filesystem".

21)

   o  In the case of non-matching server scopes, the text does not
      mention transparent state migration at all, resulting in a
      functional regression from NFSV4.0

"." at end.

22)

8.  Lock State and File System Transitions (AS PROPOSED)

Looks like more confusion on "file system" versus "filesystem".

Many more instances in the document.

23)

As I look at the flow of the different sections, I see Sections 1-4 and 7
as describing general problems, but not describing solutions. I see Sections 5, and 8
as describing very specific problems and describing solutions.

I am confused as to why the content in Section 6 is far away from the content in Section 3.

We do not have a means to detect an implementation (whether client or server)
which supports 3530, 3530bis, or this document. We are not going to have one.

I would remove the discussion about that from the document and focus on:

1) What motivates you developing NUCS and UCS models?
2) What changes have to be implemented in order to achieve best interoperability?