Mora, Jorge | 4 Mar 00:46 2015
Picon

NFSv4.2 XDR proposed changes for COPY operation

Currently the results for server-side copy operation is as follows:

struct COPY4res {

        nfsstat4        cr_status;

        write_response4 cr_response;

        bool            cr_consecutive;

        bool            cr_synchronous;

};


The results for the COPY operation should be a union like the following:


struct copy_requirements4 {

        bool            cr_consecutive;

        bool            cr_synchronous;

};


struct COPY4resok {

        write_response4    cr_response;

        copy_requirements4 cr_requirements;

};


union COPY4res switch (nfsstat4 cr_status) {

case NFS4_OK:

        COPY4resok         resok4;

case NFS4ERR_OFFLOAD_NO_REQS:

        copy_requirements4 requirements;

default:

        void;

};



—Jorge

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
internet-drafts | 3 Mar 19:18 2015
Picon

I-D Action: draft-ietf-nfsv4-minorversion2-dot-x-31.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           : NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description
        Author          : Thomas Haynes
	Filename        : draft-ietf-nfsv4-minorversion2-dot-x-31.txt
	Pages           : 80
	Date            : 2015-03-03

Abstract:
   This Internet-Draft provides the XDR description for NFSv4 minor
   version two.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2-dot-x/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-dot-x-31

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-minorversion2-dot-x-31

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

internet-drafts | 3 Mar 19:14 2015
Picon

I-D Action: draft-ietf-nfsv4-minorversion2-31.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           : NFS Version 4 Minor Version 2
        Author          : Thomas Haynes
	Filename        : draft-ietf-nfsv4-minorversion2-31.txt
	Pages           : 95
	Date            : 2015-03-03

Abstract:
   This Internet-Draft describes NFS version 4 minor version two,
   describing the protocol extensions made from NFS version 4 minor
   version 1.  Major extensions introduced in NFS version 4 minor
   version two include: Server Side Copy, Application I/O Advise, Space
   Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-31

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-minorversion2-31

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

Adamson, Andy | 27 Feb 20:50 2015
Picon

NFSv4.2 draft inter server copy correction

Hi Tom

in 4.10.1.2.  Inter-Server Copy via ONC RPC without RPCSEC_GSS:

   The client will then send these URLs to the destination server in the
   COPY operation.  Suppose that the 192.0.2.0/24 network is a high
   speed network and the destination server decides to transfer the file
   over this network.  If the destination contacts the source server
   from 192.0.2.56 over this network using NFSv4.1, it does the
   following:

   COMPOUND  { PUTROOTFH, LOOKUP "_COPY" ; LOOKUP
      "FvhH1OKbu8VrxvV1erdjvR7N" ; LOOKUP "203.0.113.56"; LOOKUP "_FH" ;
      OPEN "0x12345" ; GETFH }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don’t think we want to do an OPEN  from the destination server, because we already have an open stateid,
and doing an OPEN from the destination server will conflict with:

4.4.1.  Locking the Files


   Both the source and destination file may need to be locked to protect
   the content during the copy operations.  A client can achieve this by
   a combination of OPEN and LOCK operations.  I.e., either share or
   byte range locks might be desired.


I also think the GETFH is not needed, as the COPY compound has the SAVE_FH which provides the FH of the file to READ.

—>Andy
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Olga Kornievskaia | 26 Feb 16:43 2015
Picon

NFS4.2 inter-server copy spec concern

Hi folks,

I'd like to raise a concern that the current specification in COPY_NOTIFY is insufficient (or maybe that it makes implementation unnecessary complicated on the servers).

At the time of COPY_NOTIFY, the source server needs to remember cna_src_stateid and match it to the corresponding READ request from the destination server. 

My first concern is about matching ips. At the time of COPY_NOTIFY, the source server has the destination server ip provided by the client, using the spec example say it's 203.0.113.56. Thus the source server can store say cna_src_stateid=0xf00bar and cna_destination_server=203.0.113.56. Yet, the READ can come from 192.0.2.56 which won't match any stored values. The only thing that source server can check is that READ came from the same subnet, 192.0.2.0/24 for which it included its ip of 192.0.2.18 in the cnr_source_server list in the reply of COPY_NOTIFY. Thus, I don't see how's possible to verify that READ request came from the destination server the client specified in COPY_NOTIFY (unless it's mandated that the destination server MUST use the same ip used with the client).

My second concern is regarding uniqueness of stateid. There is only a guarantee of uniqueness of stateids for a clientid. Two different clientids that open the same file can get the same stateid. Thus, if we have two copies initiated from two different clientids, then the source server is required to deal with non-uniqueness by either ref counting or allowing for duplicates on the list. If gssv3 is used then we can use the generated shared secret to provide us a lookup key for stateids to be matched. However, spec allows for non-gssv3 implementation. Using user identity (i.e., user <at> nfsdomain) as a key also doesn't seem to work because the destination server will be making the READ as user <at> nfsdomain in gssv2. Maybe ref counting or duplicate entries is a perfectly fine implementation but seems like if we added a random_number to COPY_NOTIFY (as is suggested for things like urls) it would make implementation must easier. 

Thank you.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Olga Kornievskaia | 24 Feb 22:12 2015
Picon

NFSv4.2 inter-server question

Hi Tom,

Minor typos: 
1. I noticed that section 4.2.2, 3rd paragraph, has COPY_NOTICE instead of COPY_NOTIFY.
2. In 15.3.3, there is a mention of COPY_REVOKE, I'm assuming that it's OFFLOAD_CANCEL?

Question:
In 15.2.3, 6th paragraph, it says:
For an intra-server copy, both the ca_src_stateid and ca_dst_stateid MUST refer to either open or locking states provided earlier by the server.
Can this be a delegation stateid? Or it must be open stateid or locking stateid? (my question is for intra-server copy as well).
Also in general, if a client has a delegation for the source file it's copying and allowed to use it for the copy, should there be some guidance in the spec regarding dealing with recall of that delegation. Does the client must wait until the copy completes before returning the delegation? I imagine that otherwise, the destination server that uses that stateid in the READ can fail with a BAD_STATEID error.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 20 Feb 23:36 2015
Picon

preliminary agenda has been published for ietf92

 

And the NFSv4 WG meeting has been scheduled for Thursday, March 26th at 9am.

 

Final agenda will be published next Friday.

 

I-D submission cut-off is March 9th.

 

WG draft agendas are due on March 9th as well – please send me your agenda items (even if you already submitted a suggestion).

 

Thanks,

Spencer

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Adamson, Andy | 20 Feb 18:23 2015
Picon

NFSv4.2 draft 30 Inter server to server corrections

Hi Tom

1) COPY NFS4ERR_STALE clarification

15.2.3.  DESCRIPTION

   If the request is for a server-to-server copy, the source-fh is a
                                ^^^^^^^^^^^^^^^^^^^
This should be “an inter-server-to-server copy"


   filehandle from the source server and the compound procedure is being
   executed on the destination server.  In this case, the source-fh is a
   foreign filehandle on the server receiving the COPY request.  If
   either PUTFH or SAVEFH checked the validity of the filehandle, the
   operation would likely fail and return NFS4ERR_STALE.

   If a server supports the server-to-server COPY feature, a PUTFH
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This should be “For an inter-server copy”, a PUTFH

   followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either
   operation.  These restrictions do not pose substantial difficulties
   for servers.  The CURRENT_FH and SAVED_FH may be validated in the
   context of the operation referencing them and an NFS4ERR_STALE error
   returned for an invalid file handle at that point.


2) Inter-server copy using NFSv4.x and source server clientid check on the READ stateid.


4.7.2.  Using NFSv4.x as the Copy Protocol


   The destination server MAY use standard NFSv4.x (where x >= 1)
   operations to read the data from the source server.  If NFSv4.x is
   used for the server-to-server copy protocol, the destination server
   can use the source filehandle and ca_src_stateid provided in the COPY
   request with standard NFSv4.x operations to read data from the source
   server.

We need to add some text here concerning the source server receiving the ca_src_stateid in an NFSv4.x READ
operation from the destination server. At issue is the fact that the destination server will present the
cn_src_stateid under a different clientID (perhaps no clientID in the case of NFSv4.0)  to the source
server than the clientID that the cn_src_stateid was created under (the client clientID at OPEN or
OPEN/LOCK). So it should be made clear that in the case of an inter-server copy that uses NFSv4.x as the copy
protocol, the source server should expect and allow a different clientID for the READ stateid coming from
the destination server for a file handle/statied pair ‘registered’ via a COPY_NOTIFY. In other
words, an error such as NFS4ERR_BAD_STATEID should not be returned for the case of a clientID 
cn_src_stateid mis-match.

—>Andy
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Mora, Jorge | 11 Feb 22:02 2015
Picon

draft-ietf-nfsv4-minorversion2-30.txt

Hello Tom,

In section 13 (Operations: REQUIRED, RECOMMENDED, or OPTIONAL), the SEEK operation is not
listed on the Operations table.


—Jorge

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Mora, Jorge | 11 Feb 21:57 2015
Picon

draft-ietf-nfsv4-minorversion2-30.txt

Hello Tom,

Error in section 8.4, word archived used instead of achieved:

8.4. An Example os Zeroing Space

   A simpler use case for WRITE_SAME are applications that want to

   efficiently zero out a file, but do not want to modify space

   reservations.  This can easily be archived <— achieved



—Jorge


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Benny Halevy | 11 Feb 11:34 2015
Picon

draft-ietf-nfsv4-flex-files-05 review

Tom,

Thanks for the draft update.
Following are a few minor comments for your consideration.

Thanks,

Benny

1) Section 2.1. LAYOUTCOMMIT
>
> With a loosely coupled system, a LAYOUTCOMMIT to the metadata server MUST
> be proceeded with a COMMIT to the storage device.

It would be technically correct to restrict this requirement "when the
data server had not previously committed the data file's written data
as STABLE_FILE"

2) Section 2.2. Security Models

s/it forced/it is forced/

s/can hand out/MAY hand out/
to make it clear that's up to the metadata server's policy

3) Section 2.2.2. Example of using Synthetic uids/gids

s/modificaations/modifications/

4) Section 5.1. ff_layout4

> For loosely coupled storage devices, ffds_user and ffds_group provide
> credentials to be used by the client to access the data files.

Since ffds_user and ffds_group are per data file, I'd consider
rephrasing the above as:

For loosely coupled storage devices, ffds_user and ffds_group provide
credentials to be used by the client to access each data file.

5) References, [NFSv42]

At the time of this update, draft-ietf-nfsv4-minorversion2 is already at -30
Although RFC Editor needs to fix this anyhow before this draft can be
come an rfc
-30 changed lea_errors into lea_errors<> and that provides the
justification for repeating
this change here...

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


Gmane