Subject: [nfsv4] NFSv4.2 COPY comments

From: Christoph Hellwig <[email-masked]>
Date: Wed, 18 Mar 2015 14:51:46 +0100

"The COPY operation requests that a file be copied from the location
 specified by the SAVED_FH value to the location specified by the CURRENT_FH."

	I don't think that is correct.  It is used to copy a range from
	the source file to the destination file, but not the file itself,
	a lot of clutter later on seems to be based on this confusion, so if
	we clarify this early on much of that could go away.  E.g.:

"Note, the file MUST exist before the COPY operation begins. It is the
responsibility of the client to create the file if necessary, regardless of the
actual copy protocol used. If the file cannot be created in the destination
file system (due to file name restrictions, such as case or length), the COPY
operation MUST NOT be called."

" The copying of any and all attributes on the source file is the
responsibility of both the client and the copy protocol. Any attribute which is
both exposed via the NFS protocol on the source file and set SHOULD be copied
to the destination file. Any attribute supported by the destination server that
is not set on the source file SHOULD be left unset. If the client cannot copy
an attribute from the source to destination, it MAY fail the copy transaction.

Metadata attributes not exposed via the NFS protocol SHOULD be copied to the
destination file where appropriate via the copy protocol. Note that if the copy
protocol is NFSv4.x, then these attributes will be lost.

The destination file's named attributes are not duplicated from the source
file. After the copy process completes, the client MAY attempt to duplicate
named attributes using standard NFSv4 operations. However, the destination
file's named attribute capabilities MAY be different from the source file's
named attribute capabilities."

	Both these sections can go away if it is made clear from the
	beginning that we only copy ranges of data, and not "files".

"The SAVED_FH must be a regular file."
"The CURRENT_FH MUST be a regular file and not a directory."

	Why do we use different language for the two cases?

" If the operation does not result in an immediate failure, the server will
return NFS4_OK, and the CURRENT_FH will remain the destination's filehandle."

	I can't see a case where CURRENT_FH would not remaing the
	current file handle.

---

From: [email-masked] (J. Bruce Fields)
Date: Wed, 18 Mar 2015 15:13:12 -0400

> 	we clarify this early on much of that could go away.  E.g.:

Originally COPY actually created the destination file--that was torn out
at some point, and probably not all the language was fixed.  Definitely
in favor of cleaning that up.

> 	beginning that we only copy ranges of data, and not "files".

Agreed.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 18 Mar 2015 15:59:40 -0400

Also, does anyone have pointers to justification for the netloc4 cases?:

	union netloc4 switch (netloc_type4 nl_type) {
		case NL4_NAME:          utf8str_cis nl_name;
		case NL4_URL:           utf8str_cis nl_url;
		case NL4_NETADDR: netaddr4    nl_addr;
	};

Does anyone really want to have to implement multiple server-to-server
protocols?  Couldn't we just pick one?

Also, why do we need both names and addresses?  Is anyone planning an
implementation for which addresses would be insufficient?

--b.

---

From: Tom Haynes <[email-masked]>
Date: Wed, 18 Mar 2015 13:22:29 -0700

> On Mar 18, 2015, at 12:59 PM, J. Bruce Fields <[email-masked]> wrote:
> 

I think this came from the NetApp prototype which used a proprietary copy engine.

And I think they used a NL4_URL for that.

> implementation for which addresses would be insufficient?

Completeness? idk