David Noveck | 28 Oct 16:23 2014
Picon

draft haynes-nfsv4-versioning: Issues relating to opcode assignments etc.

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

Just to clarify here, the draft in question would be a draft (i.e. typically the first draft) of a working group document.  No assignments by publishing individual drafts are contemplated.

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

I did recall Christoph asking about this but I didn't recall any controversy.  I've looked for the email in which this was discussed but haven't found it.

There are some issues here that need to be clarified, whether "controversy" is the right word or not.  Also, It makes sense to consider issues related to assignment of attribute numbers, other enums, and flag bits, at the same time we consider operation code assignment (including those for callbacks, I assume).

I think we need to distinguish a couple of related issues:
  • How (or by whom) the assignment is made.
  • When the assignment is made
I think the issue about which there is likely to be disagreement or controversy will be the question of when (i.e. how early) the assignment is to be made. My understanding of the connection between these two issues is as follows:
  • If the assignment is to be made when the RFC is published, then we could implement IANA-based assignment by creating one or more registries with a "specification required" assignment policy.  However, this could be complicated to do, although it is relatively simple if you just do it for operations.  The big issue is that doing this doesn't buy you anything (see below for a discussion of this).
  • If the assignment is to made earlier than that (e.g. when the document becomes a working-group document as suggested in the current draft), it isn't clear how to specify an assignment policy that IANA would accept.
If IANA is to be making the assignment, I'll  assume the assignment policy people are thinking about is "specification required", essentially meaning you have to have an RFC.   If there's been any discussion of a different assignment policy, I haven't heard of it. 

If we are talking about assignments being made (or at least becoming effective) at RFC approval time, I don't see how an IANA registry will add anything to the process.  For example, we could have set up an opcode registry when RFC3530 was published and then added the v4.1 opcodes to it when RFC5662 was published.  Further assignments could be made when the v4.2 XDR RFC is published.

If we had done that (and possibly set up registries for callbacks and attributes) that would not have added anything to the process.  It's also a lot of work to set up registries, including additional ones for various enums and flag bits.  There's a good reason we chose not to do that and I don't see what has changed to make this more desirable now.

So now let's turn back to the issue of when the assignment is to be made.  The following list is intended to summarize the issues raised regarding the approach outlined in draft-haynes-nfsv4-versioning-01.  It is likely not to be complete, as I can't remember what Christoph said about the issue and it's possible that I've forgotten other stuff as well.
  • Benny raised issues regarding the potential existence of holes in the set of opcode and attribute assignments.  He was concerned about the performance implications.  This didn't turn into a controversy, but in my mind this remains an open issue which the working group should come to a consensus  on. Personally, I don't feel that the performance issues are significant enough to arouse concern.
  • Tom had some concerns that, while not explicitly directed to the time-of-opcode-assignment issue, may be relevant here.  Tom was concerned about situations in which an (unofficial) assignment was made, and code was shipped on the basis of that assignment, making it difficult to change that assignment, without impacting those running the previously shipped code. 
This issue could have some bearing on the time-of-assignment question but it could be argued both ways.  First, if one is concerned about assignments being made too early, that might argue for either a later assignment point (e.g RFC approval) or the group being a little more restrained about the implementation of a earlier assignment policy (i.e. the working group taking due note of the consequences of making an assignment at the point the document is made a working group document.

Also, if one is concerned about the consequences, of people shipping code that depends on assignments not formally made, this would argue against an assignment policy subject to unpredictable delays.  Maybe I've been unduly influenced by experiences with rfc3530bis, but i think that if you have a policy that requires IESG approval and going through the RFC editing process, one will sometimes wind up needing to ship code without waiting for the process to complete.  My fear is that if one has a policy like that, one may be faced with the choice of discouraging reasonable implementation progress or violating ones own rules. That's what led me to choose the policy of assignment at the time that the feature specification document becomes a working group document.  
  • Possibly (tangentially) related to this issue are Benny's remarks regarding assignment of experimental ranges for attributes, opcode and potentially other feature elements.   While it is true that such ranges could support some degree of experimental use, I would have to say that is so only in a very limited context.    It seems to me that the model is doing something in a very constrained environment in which the code you write is restricted environment and you don't want to let it escape into the wild, since the opcodes in the experimental assignments cannot be relied upon, since they are inherently transient.  Let's call that alpha-test-style experimental use.
The provisional assignments that are to be made as described in draft-haynes-versioning-01 allow something that we might cal beta-test-style experimental use.  The idea is that we may at times, need to get the benefit of something nearer real use, as we dot the i's and cross the t's on the spec.  In many cases, there needs to be extensive specification work, and that work, while necessary to support the most general sort of use, does not affect a large portion of typical use and there are benefits to be had from getting that experience earlier.  As an example, consider server-side copy, first proposed in an I-D in early 2009.  A lot of the work from that time to now concerned it's extension to the case of inter-server copy and exploring the security issues posed by the requirement that the protocol not require a trust relationship between the source and destination servers.  If we could have beta-tested the subset of the protocol dealing with the intra-server copy, the NFSv4 user community would have gotten the benefits of that subset of the server-side copy feature, while the security issues in the inter-server case were addressed.

So to summarize where I stand on these issues:
  • I think the real issue here concerns the time at which it is appropriate to  make these assignments and that once that decision is made, whichever way the group makes it, adding IANA to the process is not a help.
  • If someone wants to make the case for IANA involvement in this process, the working group should address that issue.
  • I see no reason to modify the time-of-assignment approach specified in draft-haynes-nfsv4-versioning-01, but think that there may be reason for the working group to discuss this further.
  • Although I continue to think early assignment is a better choice, I'm not all that invested in that choice.  For me, getting rid of feature batching (section 5 of the document) and providing a clear path to correcting XDR problems discovered after RFC publication (section 6 of the document) are the big benefits of the current draft and my focus is on those.
  • I'd like to see us come to a consensus on this issue but don't think it is required for going forward and making this a working group document.  Even if we do come to a consensus on this issue, it may change before we reach WGLC.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 26 Oct 12:16 2014
Picon

new WG document in action

 

As you may have noticed, Andy’s document on “Multiple NFSv4 Domain File System Requirements” was submitted and is now a WG document that can be found here:

 

http://www.ietf.org/id/draft-ietf-nfsv4-multi-domain-fs-reqs-00.txt

 

Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
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/

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

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


Gmane