Subject: [nfsv4] Scribe 6/22

From: "Reyes-Ortiz, Talia" <[email-masked]>
Date: Fri, 22 Jun 2012 01:33:31 +0000

Tom, Chuck, Dean, Manjunath, Sorin, Trond, Talia

Note-well agreement.

START Line 1369

1393 - Chuck: Concern about the wording for direct IO

1498 - Chuck: Wants to add a sentence about communication of caching requirements.

1550 - Chuck:  consolidate all of the IANA considerations into one example

3995 - Chuck: "stated" should be "state_ID"

4004 - Chuck: Instead "Once delegated to a client a server might never receive another I/O request for the file" Change to "Once delegated to a client and the client has read the content for that byte range, a server may never receive a read request"

1524 - Chuck: client restart scenario describe, discuss more

4009 - Trond: Combine the two sentences

4009 - Dean: If it doesn't recognize the hint it returns an error

4007 - Dean: Tighten up what "properly formed" mean and "does not recognize" means

4024 - Chuck: Discussion on if the client hint send inside the compound, or not

4060 - Trond: Strike that paragraph

4214 - Dean: specify what "one time" means

END
Cheers!
Talia Reyes-Ortiz
Program Manager
CTO Office
NetApp Inc.
408.822.1566 Direct Phone
[email-masked]
[Description: http://media.netapp.com/images/esigs-innovative-company-480x75.png]<http://www.forbes.com/special-features/innovative-companies.html>

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 22 Jun 2012 15:03:15 +0000

From: <Reyes-Ortiz>, Talia <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 21, 2012 8:33 PM
To: nfsv4 <[email-masked]<mailto:[email-masked]>>
Subject: [nfsv4] Scribe 6/22

4009 – Trond: Combine the two sentences

4009 – Dean: If it doesn’t recognize the hint it returns an error

4007 – Dean: Tighten up what “properly formed” mean and “does not recognize” means

 So we have this paragraph:

  4007     The server will return success if the operation is properly formed,
  4008     otherwise the server will return an error.  The server MUST NOT
  4009     return an error if it does not recognize or does not support the
  4010     requested advice.  This is also true even if the client sends
  4011     contradictory hints to the server, e.g., IO_ADVISE4_SEQUENTIAL and
  4012     IO_ADVISE4_RANDOM in a single IO_ADVISE operation.  In this case, the
  4013     server MUST return success and a ior_hints value that indicates the
  4014     hint it intends to optimize.  For contradictory hints, this may mean
  4015     simply returning IO_ADVISE4_NORMAL for example.

And I'm proposing to replace it with:

      Since IO_ADVISE is a hint, a server SHOULD not return an error
      and invalidate a entire Compound request if one of sent hints is not
      supported by the server.  Also, the server MUST NOT
      return an error if the client sends contradictory hints to
      the server, e.g., IO_ADVISE4_SEQUENTIAL and
      IO_ADVISE4_RANDOM in a single IO_ADVISE operation.  In these cases, the
      server MUST return success and a ior_hints value that indicates the
      hint it intends to optimize. This may mean
      simply returning IO_ADVISE4_NORMAL.

---

From: Dean <[email-masked]>
Date: Wed, 27 Jun 2012 09:17:58 -0700

Hi Tom,

(sorry if this is sent twice)

Thank you for editing the paragraph.  couple comments,
>       Since IO_ADVISE is a hint, a server SHOULD not return an error
not -> "NOT"?
>       and invalidate a entire Compound request if one of sent hints is not
Sounds like a legal doc, how about, "...request if any IO_ADVISE_type4 

>       hint it intends to optimize. This may mean
It sounds like we are optimizing a hint, instead of an access pattern.  
How about replace optimize -> implement?
Dean
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 27 Jun 2012 16:36:08 +0000

From: Dean <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 27, 2012 11:17 AM
To: nfsv4 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nfsv4] Scribe 6/22

Hi Tom,

Ack

      and invalidate a entire Compound request if one of sent hints is not
Sounds like a legal doc, how about, "...request if any IO_ADVISE_type4 value in iar_hints is not supported by the server.:

And you just got all geeky.

… request if any hint in iar_hints is not …

We use the phrase "any hint in " with iar_hints and ior_hints elsewhere.

It sounds like we are optimizing a hint, instead of an access pattern.  How about replace optimize -> implement?

Ack

Dean

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

---

From: <[email-masked]>
Date: Wed, 27 Jun 2012 12:42:56 -0400

> It sounds like we are optimizing a hint, instead of an access pattern.  How about replace optimize -> implement?

How about "act upon"?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Sent: Wednesday, June 27, 2012 12:18 PM
To: [email-masked]
Subject: Re: [nfsv4] Scribe 6/22

Hi Tom,

nfsv4 mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 27 Jun 2012 16:55:33 +0000

1550 – Chuck:  consolidate all of the IANA considerations into one example

3.2.  IANA Considerations

   The IO_ADVISE_type4 will be extended through an IANA registry.

Why do we need a IANA registry? With the way this chapter is written, there is no way to implement a change to the registry without bumping the minor version for the protocol.

Contrast this with LFS (label format specifiers) for Labeled NFS, these values can change outside of the minor version and safely be handled by that version.

If we want to use an IANA registry for IO_ADVISE, we need to make the iar_hints field be opaque.

Or we can strike this section out and just define new hints in new minor versions.