Subject: [nfsv4] [NFSv4.2] Meeting Agenda for 4/21/11

From: Thomas Haynes <[email-masked]>
Date: Wed, 20 Apr 2011 19:02:04 -0500

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

   Time: Thursdays 12:30-1:30 PM CST/1:30-2:30 PM EST/10:30-11:30 AM PST
Dial-in: 1-888-765-3653 (us)
         303-218-2659 (international)
     Id: 2787108

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.

+ Unstable file creation

Trond presented a new feature request in Prague that would deserialize
file creation (think untar). 

+ New I/O ops

++ Do we want to support large reads and writes?

The pro of doing so is that we change read and write ops once in 4.2. The
con is that support is not there yet.

++ Do we want to have an union which does holes/patterns/data?

Holes of zeros are a reality now and patterns are a proposal in part from a major 
database vendor.

We should expect to see the same sparse file savings
with patterns as we do with holes. 

We do not yet know the ratio of how often holes appear versus patterns.

Pro: Reduces wire footprint for zero holes.
Con: Introduces complexity in the XDR.

++ Do we want short reads or arrays of holes/patterns/data?

++ WRITE_PATTERN will do pattern initialization and hole punching.

Server implementations may return NFS4ERR_NOTSUPP for this
functionality. But even if they do not support sparse files, they may
chose to support minimizing traffic across the wire. I.e., they
may chose to write disk blocks with the pattern.

As this might be a long running operation (think of initializing your
VM's disk image when you create a new VM), do we either
want to leverage the proposed COPY mechanism or use a
CB to inform the client when the storage has been created?

++ For pNFS:

READ_PLUS goes to the DS (and MDS for Asynch I/O)

This would be for data and patterns. Potentially large I/O.

WRITE[_PLUS] goes to the DS (and MDS for Asynch I/O)

This would be for data only. If we do large I/O, then it will be called WRITE_PLUS.

WRITE_PATTERN goes to the MDS

Questions:

1) Does it force layouts to be recalled?