Re: [nfsv4] Server-side copy question

["J. Bruce Fields" <[e-mail]>]

On Thu, Feb 23, 2017 at 04:46:33PM -0500, David Noveck wrote:
> > I think what we really want is to change the MUST to something weaker
> > (MAY?).
> 
> I think we should stay away from the question of what we really want,
> since everybody's preferences are different.
> 
> Fortunately, we don't need agreement/consensus on that.  Anyone,
> can submit an errata.  All you need is a suggested corrected text that
> people will not object strongly to and will regard as an improvement.
> Given how broken the existing text is, that is a pretty low bar.
> 
> I have already suggested using MAY so I'm on board.  Trond
> had some objections but if he can't come up with something better,
> I don't think he'll object to your approach.
> 
> > Maybe it doesn't work, but I the intention was to allow COPY to be
> > implemented by either a copy-like or clone-like backend.
> 
> That's fine but the question is going to be about how such a client
> deals with server's who manifest behavior A, mandated by RFC 7862
> and allowed by the corrected text we are discussing.
> 
> > So, my only worry would be to avoid clients that are unprepared to deal
> > with a short read.  Thankfully I think short reads are already allowed
> > for other reasons, so I think the risk of a major interoperability
> > problem here is low?
> 
> Given that this only occurs in the range case, which is quite rarely used,
> the chance of a "major" interoperability problem is not low or
> infinitesimal.
> It is zero.

The Linux server implementation currently caps the amount of data copied
at 4MB, returning a short result instead, to prevent arbitrary long
copies.  (Partly because we didn't want to implement async copy at
first.) 

So an app might do something like:

	offset = 0;
	while (copied = copy_file_range(fdin, offset, fdout, offset,
							len, flags) > 0)
		offset += copied;

So I expect the range case to be the normal case there even when copying
the whole file.  But we're also counting on clients and apps to handle
short copy results.

(Hm, linux's copy_file_range isn't documented to have the "0 == copy to
end of file convention".  That's a potentially ugly mismatch?  Not sure
if our API can or should be fixed.)

The possibility that the copy could return either a short read or EINVAL
make this all kind of annoying.  You might end up having to do something
like

	offset = 0;
	while (1) {
		copied = copy_file_range(fdin, offset, fdout, offset,
							len, flags) > 0)
		if (copied == -EINVAL) {
			/* Uh, I dunno, maybe stat the file for a new
			 * length and retry? */
		} else if (copied < 0)
			/* error out */
		else 
			offset += copied;
	}

But, anyway, I guess that's doable.

--b.