internet-drafts | 25 Oct 17:33 2014
Picon

I-D Action: draft-ietf-nfsv4-multi-domain-fs-reqs-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Multiple NFSv4 Domain File System Requirements
        Authors         : William A. (Andy) Adamson
                          Nicolas Williams
	Filename        : draft-ietf-nfsv4-multi-domain-fs-reqs-00.txt
	Pages           : 13
	Date            : 2014-10-23

Abstract:
   This document describes constraints to the NFSv4.0 and NFSv4.1
   protocols as well as the use of multi-domain capable file systems,
   name resolution services, and security services required to fully
   enable a multiple NFSv4 domain file system, such as a multiple NFSv4
   domain Federated File System.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-multi-domain-fs-reqs/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-multi-domain-fs-reqs-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

(Continue reading)

David Noveck | 24 Oct 23:54 2014
Picon

extensions to callbacks and replies

This is my response to the discussion of the open issue that Tom cited regarding extensions to the set of callbacks, which was extended by Bruce to cover extensions to replies as well.

I think the discussion uncovered significant issues which should be addressed in draft-haynes-nfsv4-versioning-02 (or draft-ietf-nfsv4-versioning-00).  Here's some proposed changes for people to comment on.  I hope I've addressed all the issues that people brought up.  Let me know if I've missed something.


The penultimate unbulleted paragraph of section 5.1 (the one now at the top of page 8) is modified.  Strike the final "In particular:" and add a new paragraph after that which reads as follows:

Because the receiver of a message may be unaware of the 
existence of a specific extension, certain compatibility 
rules need to be observed.  In some cases (e.g addition of 
new operations or callbacks or addition of new arms to an 
existing switched union) older clients or servers may be 
unable to do XDR parsing on an extension of whose existence 
they are unaware.  In other cases (e.g. error returns) there 
are no XDR parsing issues but existing clients and servers 
may have expectations as to what may validly be returned. 
Detailed discussion of these compatibility issues appears below:

   o Issues related to messages sent to the server are discussed 
     in section 5.1.1. 

   o Issues related to messages sent to the client are discussed 
     in section 5.1.2.

Begin a new section at this point:  The beginning should read;

  5.1.1.   Compatibility issues for messages sent to servers.

This section deals with compatibility issues that relate to
messages sent to the server, i.e. requests and replies to callbacks.  
In the case of requests, it is the responsibility of the client to 
determine whether the server in question supports the extension in
question before sending a request containing it for any purpose 
other than determining whether the server is aware of the extension.  
In the case of callback replies, the server demonstrates its awareness 
of proper parsing for callback replies by sending the associated callback.

Regarding the handling of requests:


The existing bulleted list follows with the following modifications:
  • For the second bullet, add the following new sentence at the end:
Clients need to do this before attempting to use attributes
defined in an extension since they cannot depend on the 
server returning NFS4ERRATTRNOTSUPP for requests which 
include a mask bit corresponding to a previously unspecified 
attribute number (as opposed to one which is defined but 
unsupported).

  • Delete the third bulleted  item  as it now belongs in section 5.1.2.
  • In the fifth bulleted item, 'in a request" after "union". 
  • Delete the last bulleted item.

Add after the end of the existing section 5.1 the following additional paragraph:

Regarding the handling of responses to callbacks:

  o Error values returned to the server for all callbacks that do not
use new features will only be those previously allowed. Only when the server uses a new callback extension feature can a previously  invalid error value be returned.
o Callback replies may only include a new arm of an existing switched  union when the server, typically in the callback being responded to, has used a feature element associated with the feature that defined
the new switched union arm.

At this point the other new section begins:

  5.1.2.   Compatibility issues for messages sent to clients.

This sections deals with compatibility issues that relate to messages 
sent to clients, i.e. request replies and callbacks.  In both cases,
extensions are only sent to clients that have demonstrated awareness 
of the extensions in question by using an extension associated with 
the same feature.   

Regarding the handling of request replies:

  o Error values returned to the client for all requests that do not
use new features will only be those previously allowed. Only when
the server uses a new callback extension feature can a previously 
invalid error value be returned.

  o Replies may only include a new arm of an existing switched union
    when the server, typically in the request being responded to, 
    has used a feature element associated with the feature that defined    
    the new switched union arm.

Regarding the handling of callbacks, the server needs to be sure that
it only sends callbacks to those prepared to receive and parse them.

  o In most cases, the new callback will be part of a feature that
    contains new (forward) operations as well.  When this is the case,
    the feature specification will specify the operations whose receipt
    by a server is sufficient to indicate that the client issuing them
    is prepared to accept and parse the associated callbacks.

  o 
For callbacks associated with features that have no new operations
    defined, 
the feature specification should define some way for a
    client to indicate that it is prepared to accept and parse
    callbacks that are part of the extension.  For example, a
    flag bit in the EXCHANGE_ID request may serve this purpose.

    o In both of the above cases, the ability to accept and parse the
    specified callback is considered separate from support for the
    callback.  The feature specification will indicate whether support
    for the callback is required whenever the feature is used by the
    client.  In cases in which support is not required, the client is 
    free to return NFS4ERR_NOTSUPP upon receiving the callback.
      


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Chuck Lever | 23 Oct 18:29 2014
Picon

Requirements for bi-directional RPC/RDMA

An active discussion about how to implement NFSv4.1 backchannel
for RDMA-capable NFS clients is going on over on
linux-nfs <at> vger.kernel.org. See:

  http://marc.info/?l=linux-nfs&m=141407115607977&w=2

Some questions for this group are:

Does RFC 5661, 5666, or 5667 contain a requirement or
recommendation for clients or servers to support bi-directional
RPC/RDMA ? Is there a RECOMMENDED approach, or is it entirely
at an implementer’s discretion?

If there is no requirement for bi-directional RPC/RDMA, how is
interoperation to be guaranteed between an implementation that
supports bi-directional RPC/RDMA and one that does not? In
particular, are RDMA-capable NFSv4.1 servers required to support
bi-directional RPC/RDMA?

If servers are not required to support bi-directional RPC/RDMA,
one recovery method is to establish a TCP connection to the
server and use that for backchannel traffic. Would require a
minimalist form of session trunking.

If the client does not support bi-directional RPC/RDMA and
chooses not to use the above approach, an alternative is to
squelch client recovery when SEQ4_STATUS_CB_PATH_DOWN is
asserted in a SEQUENCE reply on the RDMA forechannel. Would
disable features that require a callback channel, such as
delegation; and some servers might waste effort attempting
to check the client’s callback service on every forechannel
operation.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Christoph Hellwig | 23 Oct 10:38 2014
Picon

[internet-drafts <at> ietf.org: New Version Notification for draft-hellwig-nfsv4-scsi-layout-00.txt]

I've posted a draft for a pNFS block layouts extension that ties deeper
into SCSI.  The main rational is to allow pNFS over classic SCSI transports
like Fibre Channel or SAS, but it also provides various other improvements
like better device discovery and better protection against unwanted access.

----- Forwarded message from internet-drafts <at> ietf.org -----

Date: Thu, 23 Oct 2014 01:31:20 -0700
From: internet-drafts <at> ietf.org
Subject: New Version Notification for draft-hellwig-nfsv4-scsi-layout-00.txt
To: Christoph Hellwig <hch <at> lst.de>, Christoph Hellwig <hch <at> lst.de>

A new version of I-D, draft-hellwig-nfsv4-scsi-layout-00.txt
has been successfully submitted by Christoph Hellwig and posted to the
IETF repository.

Name:		draft-hellwig-nfsv4-scsi-layout
Revision:	00
Title:		Parallel NFS (pNFS) SCSI Layout
Document date:	2014-10-23
Group:		Individual Submission
Pages:		13
URL:            http://www.ietf.org/internet-drafts/draft-hellwig-nfsv4-scsi-layout-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hellwig-nfsv4-scsi-layout/
Htmlized:       http://tools.ietf.org/html/draft-hellwig-nfsv4-scsi-layout-00

Abstract:
   Parallel NFS (pNFS) extends Network File Sharing version 4 (RFC5661)
   to allow clients to directly access file data on the storage used by
   the NFSv4 server.  This ability to bypass the server for data access
   can increase both performance and parallelism, but requires
   additional client functionality for data access, some of which is
   dependent on the class of storage used.  The main pNFS operations
   document specifies storage-class-independent extensions to NFS, the
   pNFS Block/Volume Layout (RFC5663) specifies the additional
   extensions for use of pNFS with block-and volume-based storage, while
   this document provides extensions to the pNFS Block/Volume Layout
   document to provide reliable fencing and better device
   discoverability for SCSI based shared storage devices.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

RFC Errata System | 23 Oct 10:13 2014

[Technical Errata Reported] RFC5663 (4142)

The following errata report has been submitted for RFC5663,
"Parallel NFS (pNFS) Block/Volume Layout".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5663&eid=4142

--------------------------------------
Type: Technical
Reported by: Christoph Hellwig <hch <at> lst.de>

Section: 2.8

Original Text
-------------
<section does not exist yet>

Corrected Text
--------------
2.8.  Device-ID-to-device-address

   A pNFS block volume layout server MAY signal
   device-ID-to-device-address changes to the client using the
   CB_NOTIFY_DEVICEID callback operation.

   If the change is compatible and does not require outstanding layouts
   to be recalled the server can issue a notification of type
   NOTIFY_DEVICEID4_CHANGE.

   A device-ID-to-device-address mapping change signaled by
   NOTIFY_DEVICEID4_CHANGE must not change the storage system specific
   addressing of the volume, and can only add new storage to the
   existing device.  In particular the following changes are allowed:

     o increasing the size of the underlying block device of a
       PNFS_BLOCK_VOLUME_SIMPLE volume.
     o increasing the size of a PNFS_BLOCK_VOLUME_SLICE volume if the
       underlying block device of the PNFS_BLOCK_VOLUME_SIMPLE volume
       it refers to is big enough to fit the new size.
     o increasing the size of each volume in a bsv_volumes of a
       PNFS_BLOCK_VOLUME_SLICE volume by the same amount.
     o increasing the size of the last volume in bcv_volumes of a
       PNFS_BLOCK_VOLUME_CONCAT volume.
     o adding new members to the end of bcv_volumes of a
       PNFS_BLOCK_VOLUME_CONCAT volume.

Notes
-----
Specify what device configuration changes can be supported without recalling layouts.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5663 (draft-ietf-nfsv4-pnfs-block-12)
--------------------------------------
Title               : Parallel NFS (pNFS) Block/Volume Layout
Publication Date    : January 2010
Author(s)           : D. Black, S. Fridella, J. Glasgow
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

RFC Errata System | 23 Oct 10:11 2014

[Technical Errata Reported] RFC5663 (4141)

The following errata report has been submitted for RFC5663,
"Parallel NFS (pNFS) Block/Volume Layout".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5663&eid=4141

--------------------------------------
Type: Technical
Reported by: Christoph Hellwig <hch <at> lst.de>

Section: 2.2.2

Original Text
-------------

Corrected Text
--------------
   The volume size of a PNFS_BLOCK_VOLUME_SIMPLE volume must be obtained
   by the client from the storage subsystem as no size is provided in
   the XDR. All volumes listed in bsv_volumes of a
   struct pnfs_block_stripe_volume_info4 must be the same size.  If
   the size of the volumes listed in a stripe set does not align
   to the bsv_stripe_unit, the last stripe should be treated as
   having a size of volume size modulo the stripe size.
   The volume size of a PNFS_BLOCK_VOLUME_SLICE volume is the sum
   of the volume sizes of each component listed in bsv_volumes.
   The volume size of a PNFS_BLOCK_VOLUME_CONCAT volume is the sum
   of the volume sizes of each component listed in bcv_volumes.

Notes
-----
RFC5663 provides no explanation of the volume types except for a few sparse comments in the XDR.  Explain at
least basic size related rules.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5663 (draft-ietf-nfsv4-pnfs-block-12)
--------------------------------------
Title               : Parallel NFS (pNFS) Block/Volume Layout
Publication Date    : January 2010
Author(s)           : D. Black, S. Fridella, J. Glasgow
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

RFC Errata System | 23 Oct 10:09 2014

[Editorial Errata Reported] RFC5663 (4140)

The following errata report has been submitted for RFC5663,
"Parallel NFS (pNFS) Block/Volume Layout".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5663&eid=4140

--------------------------------------
Type: Editorial
Reported by: Christoph Hellwig <hch <at> lst.de>

Section: 2.3.5

Original Text
-------------
   Block/volume class storage devices are not required to perform read
   and write operations atomically.  Overlapping concurrent read and
   write operations to the same data may cause the read to return a
   mixture of before-write and after-write data.  Overlapping write
   operations can be worse, as the result could be a mixture of data
   from the two write operations; data corruption can occur if the
   underlying storage is striped and the operations complete in
   different orders on different stripes.  When there are multiple
   clients who wish to access the same data, a pNFS server can avoid
   these conflicts by implementing a concurrency control policy of
   single writer XOR multiple readers.  This policy MUST be implemented
   when storage devices do not provide atomicity for concurrent
   read/write and write/write operations to the same data.

Corrected Text
--------------
   Block/volume class storage devices do not provide byte granularity
   access and can only perform read and write operations atomically at
   block granularity, and thus require read-modify-write cycles to write
   data smaller than the block size.  Overlapping concurrent read and
   write operations to the same data thus may cause the read to return
   a mixture of before-write and after-write data.  Additionally, data
   corruption can occur if the underlying storage is striped and the
   operations complete in different orders on different stripes.  When
   there are multiple clients who wish to access the same data, a pNFS
   server MUST avoid these conflicts by implementing a concurrency
   control policy of single writer XOR multiple readers for a given data
   region.

Notes
-----
No device classified as block device can support concurrent writes at arbitrary byte granularity, so
reword the section to not confuse the reader.  Also make it explicit that the reader XOR writer policy only
applies to different clients, as existing client implementation require layouts not to be recalled due
to their own LAYOUTGET operations.  Note that fixing this on the client also isn't feasible as the block
layout unfortunately decided to introduce it's own extent concept instead of using layouts to describe
individual I/O mappings.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5663 (draft-ietf-nfsv4-pnfs-block-12)
--------------------------------------
Title               : Parallel NFS (pNFS) Block/Volume Layout
Publication Date    : January 2010
Author(s)           : D. Black, S. Fridella, J. Glasgow
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

RFC Errata System | 23 Oct 10:08 2014

[Technical Errata Reported] RFC5663 (4139)

The following errata report has been submitted for RFC5663,
"Parallel NFS (pNFS) Block/Volume Layout".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5663&eid=4139

--------------------------------------
Type: Technical
Reported by: Christoph Hellwig <hch <at> lst.de>

Section: 2.7

Original Text
-------------
<section doesn't exist yet>

Corrected Text
--------------
2.7.  Volatile write caches

   Many storage devices implement volatile write caches that require an
   explicit flush to persist the data from write write operations to
   stable storage.  When a volatile write cache is used the pNFS server
   must ensure the volatile write cache has been committed to stable
   storage before the LAYOUTCOMMIT operation returns.  An example for
   this behavior are SCSI devices with the "Write Cache Enable" bit set,
   which require a "SYNCRONIZE CACHE (10)" or "SYNCRONIZE CACHE (16)"
   operation to write back the storage device cache.

Notes
-----
RFC5663 currently doesn't acknowledge the existence of volatile write caches, but they are common in
consumer or SMB storage systems.  Add a section that requires the server to take care of them.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5663 (draft-ietf-nfsv4-pnfs-block-12)
--------------------------------------
Title               : Parallel NFS (pNFS) Block/Volume Layout
Publication Date    : January 2010
Author(s)           : D. Black, S. Fridella, J. Glasgow
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Tom Haynes | 23 Oct 06:08 2014

draft-haynes-nfsv4-versioning-01

So this looks good to go with only two open items for me:

1) Are new operations assigned by IANA or by publishing a draft?

Actually Christoph’s observation, but there seems to be controversy here. :-)

2) With respect to callbacks:

   o  New callbacks will only be sent to clients that have used the new
      features associated with them, allowing existing clients to be
      unaware of their existence.

What if the new feature is only implemented with callbacks?

I.e., clients have to be able to respond with not supported as well.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Benny Halevy | 11 Oct 22:49 2014

Re: Fwd: New Version Notification for draft-haynes-nfsv4-versioning-00.txt

Glad to see progress on this and I like the overall direction.
From first reading I have a couple editorial level comments.

1) Did you avoid capitalization of "may" and "must" on purpose?

For example:
Minor versions may append attributes
Minor versions must not modify the structure of an existing operation's arguments or results.

However:

A client and server that support minor version X SHOULD support minor versions 0 through X-1 as well.
2 There seems to be an extra sentence pasted here:
Such feature definition documents would contain a number of Addition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 of features to an existing minor version will take advantage of the
3) The following paragraph need to refer to servers supporting v4.2 and up.
o Existing server implementations that do not recognize the new arm of a switched union will return will return NFS4ERR_INVAL or NFS4ERR_UNION_NOTSUPP, enabling the client to determine that the the new union arm is not supported by the server.
4) Security and IANA considerations
Rather than stating that there are no considerations I'd basically repeat what was said above:

o Minor version and feature specification will include the "Security Considerations" / "IANA considerations" (respectively) section
as required for RFC publication.

5) IANA considerations
So who's assigning values to added bits / enums for new features and when in the process?
I envision multiple features being worked on in parallel by individuals so they may clash.
When accepted as a W/G document we can serialize the enumerations, yet if one a the features
lingers behind and may eventually be aborted we might end up with a "hole" in the enumeration.
Hence I think we (W/G with the help of the RFC Editor) must assign the final values upon becoming an RFC.

This could be documented as a non-consideration for IANA in this section.

Does this make sense?

Benny

On Mon, Oct 6, 2014 at 2:54 PM, Tom Haynes <thomas.haynes <at> primarydata.com> wrote:
And here it is, I ended up having to resubmit as draft-haynes-nfsv4-versioning. ;-)

Begin forwarded message:

Subject: New Version Notification for draft-haynes-nfsv4-versioning-00.txt
Date: October 6, 2014 at 2:54:14 PM EDT


A new version of I-D, draft-haynes-nfsv4-versioning-00.txt
has been successfully submitted by Thomas Haynes and posted to the
IETF repository.

Name: draft-haynes-nfsv4-versioning
Revision: 00
Title: Minor versioning Rules for NFSv4
Document date: 2014-10-06
Group: Individual Submission
Pages: 12
URL:            http://www.ietf.org/internet-drafts/draft-haynes-nfsv4-versioning-00.txt
Status:         https://datatracker.ietf.org/doc/draft-haynes-nfsv4-versioning/
Htmlized:       http://tools.ietf.org/html/draft-haynes-nfsv4-versioning-00


Abstract:
  This document specifies the minor versioning rules for NFSv4.  It
  also specifies how those minor versioning rules may be modified.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
David Noveck | 9 Oct 14:30 2014
Picon

Re: proposed text for v4.2-based conversion to a more incremental protocol extension model

>  I’m going to push out an update with Dave’s micro versioning text.

Just to clarify, I'm not proposing anything like 4.2.1.   A more incremental versioning model would address the same issues that micro-versioning was intended to, but it does so in a different way.

On Mon, Oct 6, 2014 at 2:49 PM, Tom Haynes <thomas.haynes <at> primarydata.com> wrote:

On Oct 5, 2014, at 8:51 AM, David Noveck <davenoveck <at> gmail.com> wrote:

> I'd actually like to see us pull the minorversioning out of 4.2 with a statement like:

Good idea.  Not only is it the proper response to the fact that minor versioning rules
do not belong in individual minor version documents, it also makes the v4.2 spec shorter.

It puts me under the three-page limit.  How does minus-one pages sound? :-)

> At the time this document was specified, the minorversioning are detailed in
> RFC5661. The implementer of the NFSv4.2 specification is expected to track
> the evolution of the minorversioning standard.

I think the problem may be that someone (for example, in the IESG) may ask "what minor versioning standard?".    I expect we would have to convert draft-haynes-nfsv4-minorversioning to a working group standards-track document and have our co-chairs explain this to the IESG.   I hope we are covered on charter-related issues.



So, speaking of that draft, I’m going to push out an update with Dave’s micro versioning text.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Gmane