Subject: [nfsv4] [NFSv4.2] Meeting Agenda for 5/19/11

From: Thomas Haynes <[email-masked]>
Date: Wed, 18 May 2011 19:16:46 -0500

Thursday's proposed agenda is below. Please let me know if
you would like to add additional topics.

PLEASE NOTE: Both the phone numbers and the conference ID have been changed.

   Time: Thursdays 12:30-1:30 PM CST/1:30-2:30 PM EST/10:30-11:30 AM PST
Dial-in: 1-866-844-9418 (Toll Free)
       1-517-345-9208 (Caller paid)     
         353-1-506-0479 (Israel paid)

     Id: 9744122017

Proposed Agenda
---------------

+ IETF Note Well Agreement

 This is a reminder that our discussions are governed by the 
 IETF Note Well Agreement. See:

   http://www.ietf.org/NOTEWELL.html

 We will start each week's meeting with this announcement.

+ ADB

I've sent out some pointers on end-to-end application corruption
checks. I would prefer to give people time to read and digest
those before we dive back into this discussion.

I will however break out some of the general issues we need
to deal with here.

+ enum data_content4

   enum data_content4 {
           NFS4_CONTENT_DATA = 0,
           NFS4_CONTENT_APP_BLOCK = 1,
           NFS4_CONTENT_HOLE = 2
   };

INITIALIZE and READ_PLUS will be able to both understand
ADBs and holes. INITIALIZE will not understand data.

+ ADB, Holes, and pNFS

1) How data flows:

INITIALIZE goes to MDS
READ_PLUS goes to DS

2) Mechanics

For ADB, the stripe unit size MUST be an exact multiple of the
application block size. I.e., an ADB cannot span from DSi to DSj.

sparse versus dense packing

With sparse packing, any block which would normally result
in NFS4ERR_PNFS_IO_HOLE MUST still result in that code
being sent. If the stripe unit size is 16k and the client tries
to do a 32k READ_PLUS, then the DS MUST either return
a short read or a 16k read followed by a NFS4ERR_PNFS_IO_HOLE.

A DS cannot reply about any storage it does not own.

For dense packing, the server would return either two ADBs
or two holes. It does matter for ADBs, but not so much for
holes.

+ Arm not supported

http://www.ietf.org/mail-archive/web/nfsv4/current/msg09450.html
describes the problem statement.

NFS4ERR_NOTSUPP is per operation. With discriminated unions
describing an argument to an operation, we might extend the
enumerated values when we change minor versions. We might
not make the new values MANDATORY, in which case we
might want to return an error code that differentiates between
operation not supported versus arm of the operation not supported.

+ Heterogeneous SSC and filenames with AUTH_SYS

David Black has pointed out with that the approach of using
the FH in this path:

nfs://192.168.33.18//_COPY/10.11.78.56/_FH/0x12345

is too predictable and could be used to intercept the
file. His proposal is to have a requirement that a randomized
component be presented.

+ BAT

The XDR is set. It has some LNFS added for now.

Who is bringing non-LNFS prototypes?

+ Bonus item: INITIALIZE

For ABD, both file initialization and hole punching can occur
against a server which does not support sparse files. For zero
filled hole punching, it can also occur.

It would be advantageous to have this be dealt with asynchronously,
especially as the file is large.

There are some problems to deal with here:

1) How does the server notify the client of the completion?

2) If the server reboots, how does the server know to restart zeroing?

3) If another client attempts to grab a write lock, modify data, etc
during this process, what happens?

A callback mechanism like that proposed in SSC would allow the
client to solve 1 and 2, except if the client also rebooted and/or
a network partition occurs.

For the third point, it is easy enough to calculate what to return
for a portion of the file which has not yet been modified, but what
if that client then tries to write back a change?

---

From: Dean Hildebrand <[email-masked]>
Date: Wed, 18 May 2011 18:00:41 -0700

Hi Tom,

At some point I'd like to talk about our fadvise draft and its possible 
inclusion in NFSv4.2,

http://tools.ietf.org/html/draft-hildebrand-nfsv4-fadvise-01

Dean

On 5/18/2011 5:16 PM, Thomas Haynes wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 18 May 2011 20:14:51 -0500

If we have time this week, we can start in on that. If not, then it is on the agenda for the next meeting.

One thing we are going to need to do is find the common ground with the other fadvise proposal.

On May 18, 2011, at 8:01 PM, "Dean Hildebrand" <[email-masked]> wrote:

> Hi Tom,
> 
> At some point I'd like to talk about our fadvise draft and its possible inclusion in NFSv4.2,
>

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 19 May 2011 03:38:07 +0000

Let me embellish Tom’s comment…

For proposals that overlap, I would ask that the authors/interested parties
work between themselves in an attempt to resolve into a single proposal
or approach.  At a minimum, identify for the rest of us, the main issues
and tradeoffs, etc.

Thanks,
Spencer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Wednesday, May 18, 2011 6:15 PM
To: Dean Hildebrand
Cc: [email-masked]
Subject: Re: [nfsv4] [NFSv4.2] Meeting Agenda for 5/19/11

On May 18, 2011, at 8:01 PM, "Dean Hildebrand" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

Dean

     Id: 9744122017

Proposed Agenda
---------------

+ ADB

+ enum data_content4

   enum data_content4 {
           NFS4_CONTENT_DATA = 0,

+ ADB, Holes, and pNFS

1) How data flows:

INITIALIZE goes to MDS
READ_PLUS goes to DS

2) Mechanics

+ Arm not supported

nfs://192.168.33.18//_COPY/10.11.78.56/_FH/0x12345<nfs://192.168.33.18/_COPY/10.11.78.56/_FH/0x12345>

+ BAT

+ Bonus item: INITIALIZE

nfsv4 mailing list

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

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

---

From: Dean Hildebrand <[email-masked]>
Date: Thu, 19 May 2011 09:29:57 -0700

Sounds good.  Let's kick off the conversation with a discussion on the 
NFSv4.2 bi-weekly call and then go from there on the list.

Also, to be clear, there is only 1 posix standard fadvise proposal.  The 
other proposal (enterprise apps), is merely a set of non-standard hints 
that the client can send to the server.  This is a big distinction in 
terms of the possible audience and wide spread use.

Dean

On 5/18/2011 8:38 PM, Spencer Shepler wrote:
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Haynes, Tom
> *Sent:* Wednesday, May 18, 2011 6:15 PM
> *To:* Dean Hildebrand
> *Cc:* [email-masked]
> *Subject:* Re: [nfsv4] [NFSv4.2] Meeting Agenda for 5/19/11
>
>     <nfs://192.168.33.18/_COPY/10.11.78.56/_FH/0x12345>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>