Subject: [nfsv4] wordsmithing in chapters 7 and 8

From: "Mike Eisler" <[email-masked]>
Date: Tue, 18 Mar 2008 22:11:50 -0700 (PDT)

I read through chapters 7 and 8, and several word smithing changes
to propose, in:

http://www.eisler.com/nfsv4-wg/2008-03-18-ch7-8-changes.html

(The set of changes Dave Noveck has proposed for the I/O stateid
are not in this batch).

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

---

From: Benny Halevy <[email-masked]>
Date: Wed, 19 Mar 2008 10:52:03 +0200

Looks OK to me.
The text about retransmission timeouts that longer than the
server restart and grace period is important.

Benny

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 19 Mar 2008 06:36:48 -0400

In section 8.2.1, "increment whenever LOCK" -> "incremented whenever
LOCK". 

> (The set of changes Dave Noveck has proposed 
> for the I/O stateid are not in this batch).

I just knew we'd have a merge problem but it's not a bad one.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Wednesday, March 19, 2008 1:12 AM
To: [email-masked]
Subject: [nfsv4] wordsmithing in chapters 7 and 8

I read through chapters 7 and 8, and several word smithing changes to
propose, in:

(The set of changes Dave Noveck has proposed for the I/O stateid are not
in this batch).

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 19 Mar 2008 08:22:57 -0400

> (The set of changes Dave Noveck has proposed for the I/O stateid

Couple of (mainly just wording) bugs in the changes:

      * In section 8. Page 147 'state is also valuable to offering'
        sounds odd. Perhaps you should just substitute 'state also
        offers'
      * Page 149 'Each stateid in this case represents the open for'.
        Should that be 'Each stateid in this case represents the open
        state for'?
      * Same page: 'the seqid being increment whenever' -> 'the seqid
        being incremented whenever'
      * section 8.3: 'However, if the attempt to establish a new
        connection is delayed for same reason' -> 'However, if the
        attempt to establish a new connection is delayed for some
        reason'
      * section 8.4.1: '(upon confirmation of new the client ID)' ->
        '(upon confirmation of the new client ID)'
      * Page 167: 'It is acceptable to erroneously recognize an edge
        condition and not allow a reclaim, when, with sufficient
        knowledge it would be allowed.'. What error would be returned in
        this case, and will the client still be able to recover its
        remaining locks that are not affected by the edge condition?

Cheers
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 19 Mar 2008 18:13:13 -0700 (PDT)

>         this case,
NFS4ERR_NO_GRACE_GRACE.

I've added this sentence:

 [...] would be allowed. The error the server would return in this
 case is NFS4ERR_NO_GRACE.  Note it is not known if there are other

> and will the client still be able to recover its

I don't think I've imagined a model where _NO_GRACE is returned
for some re-claim attempts, and NFS4_OK for others.

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 19 Mar 2008 18:40:36 -0700 (PDT)

> for some re-claim attempts, and NFS4_OK for others.

Let me try that again:

I don't think I've imagined a model where _NO_GRACE is returned
for some re-claim attempts, and NFS4_OK for others, with the exception
of locks that the server was able to preserve through server restart.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 31 Mar 2008 16:16:30 -0700 (PDT)

I have received no objections to this.

I did received a comment from Trond which I responded to, and did
not get a rebuttal.

Thus I will check in the changes.