Adamson, Andy | 22 Sep 18:10 2014
Picon

rewrite of draft-adamson-nfsv4-multi-domain-federated-fs-reqs

Hi

In response to your comments, I did a major rewrite of the draft. I plan to post another update for IETF91 with
the “standard” WG naming, moving this I-D to a WG item.

Please give me your comments on this re-write.

Thanks

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

The IESG | 22 Sep 16:49 2014
Picon

Last Call: <draft-ietf-nfsv4-rfc3530bis-dot-x-22.txt> (Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Network File System (NFS) Version 4 External Data Representation
   Standard (XDR) Description'
  <draft-ietf-nfsv4-rfc3530bis-dot-x-22.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-10-06. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The Network File System (NFS) version 4 is a distributed filesystem
   protocol which owes its heritage to NFS protocol version 2, RFC 1094,
   and version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
   protocol supports traditional file access, while integrating support
   for file locking and the mount protocol.  In addition, support for
   strong security (and its negotiation), compound operations, client
   caching, and internationalization have been added.  Of course,
   attention has been applied to making NFS version 4 operate well in an
   Internet environment.

   RFC3530bis formally obsoleting RFC 3530.  This document, together
   with RFC3530bis replaces RFC 3530 as the definition of the NFS
   version 4 protocol.

The file can be obtained via
(Continue reading)

The IESG | 22 Sep 16:48 2014
Picon

Last Call: <draft-ietf-nfsv4-rfc3530bis-33.txt> (Network File System (NFS) Version 4 Protocol) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Network File System (NFS) Version 4 Protocol'
  <draft-ietf-nfsv4-rfc3530bis-33.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-10-06. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The Network File System (NFS) version 4 is a distributed file system
   protocol which builds on the heritage of NFS protocol version 2, RFC
   1094, and version 3, RFC 1813.  Unlike earlier versions, the NFS
   version 4 protocol supports traditional file access while integrating
   support for file locking and the mount protocol.  In addition,
   support for strong security (and its negotiation), compound
   operations, client caching, and internationalization have been added.
   Of course, attention has been applied to making NFS version 4 operate
   well in an Internet environment.

   This document, together with the companion XDR description document,
   RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version
   4 protocol.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530bis/
(Continue reading)

Tom Haynes | 20 Sep 17:19 2014

Please push the NFSv4.2 specs into WG last call

Hi Spencer,

While the 4.2 documents cannot be published before the RPCSEC_GSSv3, they are mature enough to go through WG LC.

As such, I’ve pushed out version 27 and would like you to start the LC timer on these documents.

If there are changes due to the RPCSEC_GSSv3, we can do a mini-LC on just them.

Procedurally, I’d like to send all three documents off to the IESG at the same time and want to get these two ready:


Thanks,
Tom
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 20 Sep 03:59 2014
Picon

Agenda items for IETF 91 - Honolulu

 

I am requesting agenda items for IETF 91.  The cutoff for meeting request is next Friday, Sept 26.

 

Please have your items to me by end of day next Wednesday (9/24) so that we can make a decision if we will meet in Honolulu.

 

Spencer

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Ramanathan, Raghavendran | 18 Sep 23:18 2014
Picon

Comment/request for nfsv4.2

Hi,

 

This is a feature request in nfsv4.2.

 

Along the lines of application hints, may nfsv4.2 also provide server side hints ? I am particularly targeting the NFS4ERR_DELAY error:

 

In case of delay error, nfsv4.2 server should reply with a string – that gives a hint on why the response is delayed:

 

For any operation(using GETFH as sample below):

 

   union GETFH4res switch (nfsstat4 status) {

    case NFS4_OK:

           GETFH4resok     resok4;

    case NFS4ERR_DELAY:

           opaque          delay_why<NFS4_OPAQUE_LIMIT>;

    default:

           void;

   };

 

The opaque string “delay_why” should be a useful message that explains or hints at the exact problem the server is facing. It need not display the internal or implementation details, but it must give a clear indication of the problem the server is facing. The client may propagate this string to the application, which may choose to display it or discard it.  However, since the client might be re-trying without returning to the application, this message might be simply displayed by the client, instead of the application.  The client must not attempt to parse the string.

 

 

 

Rational:

 

When a nfs access simply hangs as below, forcing the user to send interrupt:

proto-howler(US):cthon04:ls

^C

In case of DELAY error, we cannot debug even with a packet trace, which has only requests and replies with the DELAY error.

 

 

When the above change is implemented, we get a clue using either the command line itself or the packet traces.

It is easier if the user gets a clue as below:

proto-howler(US):cthon04:ls

Nfs server 10.73.28.30 is experiencing delay in accessing user information from NIS, retrying….

 

NIS can be Files/DNS/Ldap(or anything else that may come up)

User information may be anything: group, user, hostname lookup.

 

 

Benefit: Easy to debug when we know the problem underlying the given hanging command.

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
RFC Errata System | 17 Sep 23:45 2014

[Technical Errata Reported] RFC5661 (4119)

The following errata report has been submitted for RFC5661,
"Network File System (NFS) Version 4 Minor Version 1 Protocol".

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

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

Section: 12.2.10

Original Text
-------------
A device ID lives as long as there is a layout referring to the
device ID.  If there are no layouts referring to the device ID, the
server is free to delete the device ID any time.

Corrected Text
--------------
A device ID is established by referencing it in the result of a
GETDEVICELIST or LAYOUTGET operation and can be deleted by the server
as soon as there are no layouts referring to the device ID.

If the client requested notifications for device ID mappings, the
server SHOULD send CB_NOTIFY_DEVICEID notifications for device ID
deletions or changes to the device-ID-to-device-address mappings to any
client which has used the device-ID in question at least once,
irrespective of whether the client has any layouts currently referring
to it. If the server does not support or the client does not request
notifications for device ID mappings, the client SHOULD periodically
retired unused device IDs.

Given that GETDEVICELIST does not support requesting notifications a
server that implements GETDEVICELIST MUST not not advertise support
for NOTIFY_DEVICEID4_CHANGE notification in GETDEVICEINFO, and client
using GETDEVICELIST must not rely on NOTIFY_DEVICEID4_CHANGE or
NOTIFY_DEVICEID4_DELETE notifications to work reliably.

Notes
-----
The lifetime rules in RFC5661 are contradictory - both GETDEVICELIST and CB_NOTIFY_DEVICEID
(NOTIFY4_DEVICEID_DELETE) operations imply that device IDs are valid even without layouts referring
to them. Implementations rely on this fact by caching not referenced device IDs to avoid the huge setup
costs, and thus require notifications to be sent for that case.

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. 

--------------------------------------
RFC5661 (draft-ietf-nfsv4-minorversion1-29)
--------------------------------------
Title               : Network File System (NFS) Version 4 Minor Version 1 Protocol
Publication Date    : January 2010
Author(s)           : S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.
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 | 17 Sep 23:38 2014

[Technical Errata Reported] RFC5661 (4118)

The following errata report has been submitted for RFC5661,
"Network File System (NFS) Version 4 Minor Version 1 Protocol".

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

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

Section: 20.12.3

Original Text
-------------
NOTIFY_DEVICEID4_CHANGE
  A previously provided device-ID-to-device-address mapping has
  changed and the client uses GETDEVICEINFO to obtain the updated
  mapping.  The notification is encoded in a value of data type
  notify_deviceid_change4.  This data type also contains a boolean
  field, ndc_immediate, which if TRUE indicates that the change will
  be enforced immediately, and so the client might not be able to
  complete any pending I/O to the device ID.  If ndc_immediate is
  FALSE, then for an indefinite time, the client can complete
  pending I/O.  After pending I/O is complete, the client SHOULD get
  the new device-ID-to-device-address mappings before sending new
  I/O requests to the storage devices addressed by the device ID.

Corrected Text
--------------
NOTIFY_DEVICEID4_CHANGE
  A previously provided device-ID-to-device-address mapping has
  changed and the client uses GETDEVICEINFO to obtain the updated
  mapping.  The notification is encoded in a value of data type
  notify_deviceid_change4.  This data type also contains a boolean
  field, ndc_immediate, which SHOULD be ignored by the client.
  The client may finish any outstanding I/Os that reference the
  previously provided device-ID-to-device-address mapping and SHOULD
  use GETDEVICEINFO to obtain the updated mapping for the previously
  provided device-ID-to-device-address mapping before requesting new
  layouts.  All outstanding layouts remain valid after a notification
  of type NOTIFY_DEVICEID4_CHANGE.  If the device-ID-to-device-address
  mapping changed in an incompatible way that would invalidate
  outstanding layouts, the server MUST recall all outstanding layouts
  and send a NOTIFY_DEVICEID4_DELETE notification instead.

Notes
-----
Clarify what DEVICEID4_CHANGE means vs layouts instead of I/Os. Drop the under specified ndc_immediate
flag, which can't be enforced.

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. 

--------------------------------------
RFC5661 (draft-ietf-nfsv4-minorversion1-29)
--------------------------------------
Title               : Network File System (NFS) Version 4 Minor Version 1 Protocol
Publication Date    : January 2010
Author(s)           : S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.
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

Mukherjee, Sandeep | 13 Sep 02:00 2014

pynfs enhancements


Bruce,

We have been enhancing pynfs to add object layout support. It's still work-in-progress, but we should be
able to have a working version ready by fall Bakeathon. Would it be possible to incorporate our changes to
upstream? I can share the work and do the actual push during Bakeathon.

Regards,
Sandeep

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

Christoph Hellwig | 10 Sep 02:45 2014
Picon

proposed RFC5663 errata

I'll reply with various proposed errata to RFC5663 to this mail.  They
are the result of bringing up the Linux block layout client to proper
quality standards and implementing a new server.

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

Christoph Hellwig | 8 Sep 01:56 2014
Picon

[PATCH, NFSv4.2] move GETDEVICELIST to MUST NOT implement


---
 Makefile                               |  1 +
 nfsv42_middle_errors.xml               | 19 +---------------
 nfsv42_middle_mod_op_getdevicelist.xml | 41 ++++++++++++++++++++++++++++++++++
 nfsv42_middle_op_mandlist.xml          |  2 +-
 4 files changed, 44 insertions(+), 19 deletions(-)
 create mode 100644 nfsv42_middle_mod_op_getdevicelist.xml

diff --git a/Makefile b/Makefile
index 6d68529..ab6760b 100755
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -446,6 +446,7  <at>  <at>  IDXMLSRC_BASE = \
 	${DOC_PREFIX}_middle_op_mandlist.xml \
 	${DOC_PREFIX}_middle_mod_op_start.xml \
 	${DOC_PREFIX}_middle_mod_op_exchange_id.xml \
+	${DOC_PREFIX}_middle_mod_op_getdevicelist.xml \
 	${DOC_PREFIX}_middle_mod_op_end.xml \
 	${DOC_PREFIX}_middle_op_start.xml \
 	${DOC_PREFIX}_middle_op_allocate.xml \
diff --git a/nfsv42_middle_errors.xml b/nfsv42_middle_errors.xml
index ef7a5f9..72893d4 100644
--- a/nfsv42_middle_errors.xml
+++ b/nfsv42_middle_errors.xml
 <at>  <at>  -1813,24 +1813,7  <at>  <at> 

       <c>GETDEVICELIST</c>
       <c>
-        NFS4ERR_BADXDR,
-        NFS4ERR_BAD_COOKIE,
-        NFS4ERR_DEADSESSION,
-        NFS4ERR_DELAY,
-        NFS4ERR_FHEXPIRED,
-        NFS4ERR_INVAL,
-        NFS4ERR_IO,
-        NFS4ERR_NOFILEHANDLE,
-        NFS4ERR_NOTSUPP,
-        NFS4ERR_NOT_SAME,
-        NFS4ERR_OP_NOT_IN_SESSION,
-        NFS4ERR_REP_TOO_BIG,
-        NFS4ERR_REP_TOO_BIG_TO_CACHE,
-        NFS4ERR_REQ_TOO_BIG,
-        NFS4ERR_RETRY_UNCACHED_REP,
-        NFS4ERR_SERVERFAULT,
-        NFS4ERR_TOO_MANY_OPS,
-        NFS4ERR_UNKNOWN_LAYOUTTYPE
+        NFS4ERR_NOTSUPP
       </c>

       <c>GETFH</c>
diff --git a/nfsv42_middle_mod_op_getdevicelist.xml b/nfsv42_middle_mod_op_getdevicelist.xml
new file mode 100644
index 0000000..39b7cc7
--- /dev/null
+++ b/nfsv42_middle_mod_op_getdevicelist.xml
 <at>  <at>  -0,0 +1,41  <at>  <at> 
+<!-- Copyright (C) The IETF Trust (2011) -->
+<!-- Copyright (C) The Internet Society (2011) -->
+
+<section title='Operation 48: GETDEVICELIST - Get All Device Mappings for a File System'>
+  <section toc='exclude' title="ARGUMENT">
+    <figure>
+      <artwork>
+   Unchanged
+      </artwork>
+    </figure>
+  </section>
+
+  <section toc='exclude' title="RESULT">
+    <figure>
+      <artwork>
+   Unchanged
+      </artwork>
+    </figure>
+  </section>
+
+  <section toc='exclude' title='MOTIVATION'>
+    <t>
+       The GETDEVICELIST operation was introduced in <xref target='RFC5661' />
+       specificly to request a list of devices at filesystem mount time from
+       block layout type servers.  However use of the GETDEVICELIST operation
+       introduces a race condition vs notification about changes to pNFS
+       device IDs as provided by CB_NOTIFY_DEVICEID.
+       Furthermore there is no actual need for GETDEVICELIST to implement
+       a fully working block layout server, and clients have to be able
+       to request new devices ues GETDEVICEINFO at any time in response
+       to a new deviceid in LAYOUTGET results, or in response to the
+       CB_NOTIFY_DEVICEID callback operation anyway.
+    </t>
+  </section>
+
+  <section toc='exclude' title='DESCRIPTION'>
+    <t>
+      Clients and servers MUST NOT implement the GETDEVICELIST operation.
+    </t>
+  </section>
+</section>
diff --git a/nfsv42_middle_op_mandlist.xml b/nfsv42_middle_op_mandlist.xml
index 8664f06..0786545 100644
--- a/nfsv42_middle_op_mandlist.xml
+++ b/nfsv42_middle_op_mandlist.xml
 <at>  <at>  -135,7 +135,7  <at>  <at> 
       <c>FREE_STATEID         </c> <c> REQ </c> <c>              </c>
       <c>GETATTR              </c> <c> REQ </c> <c>              </c>
       <c>GETDEVICEINFO        </c> <c> OPT </c> <c> pNFS (REQ)   </c>
-      <c>GETDEVICELIST        </c> <c> OPT </c> <c> pNFS (OPT)   </c>
+      <c>GETDEVICELIST        </c> <c> MNI </c> <c> pNFS (MNI)   </c>
       <c>GETFH                </c> <c> REQ </c> <c>              </c>
       <c>GET_DIR_DELEGATION   </c> <c> OPT </c> <c> DDELG (REQ)  </c>
       <c>LAYOUTCOMMIT         </c> <c> OPT </c> <c> pNFS (REQ)   </c>
--

-- 
1.9.1

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


Gmane