Re: [nfsv4] Server-side copy question

[David Noveck <[e-mail]>]

> > I agree but think that the most expedient way of addressing this
problem is
> > in the Linux client,  It can check against the file size before issuing
the
> > COPY request  to prevent an erroneous INVAL error being returned.

> That doesn't work, due to races with concurrent modifications to the
> file.

I'm not sure whether it works or not.  I can't find an obvious breakage
but I can't prove that none exists.

In any case, we can't consider this an easy fix for the issue.

> The server itself would seem susceptible to such races: if it implements
> the copy as a read-write loop then blocking concurrent truncates
> probably isn't reasonable, so its only choice is a short copy.  (Too
> late to return INVAL once you've written to the destination....).

That's an implementation problem that would exist no matter
what we do to the spec text under discussion.

> I really think the spec's just wrong here.'

I agree, as does Tom and Jorge as well I suppose.   Nobody has said it
was a good choice.

The question is what to do to fix it.  This is particularly difficult given
the misuse of "MUST".  The problem I'm worried about is that
the existing approach is presented as required for interoperability.
We know of cases where that approach has been followed and
the problem is that the existing spec essentially says that clients
might break if servers do something else. :-(

We know that isn't true but sombody (Spencer D?) is going to have
to convince people in the IESG of that.

So I think the focus of any correction has to be on the fact that the "MUST"
is wrong rather than on the fact (also true) that the wrong behavior was
chosen.

So here is my proposed corrected text:

When the source offset is greater than the size of the source file, the
error

is reported by failing the operation with NFS4ERR_INVAL.  Otherwise, If

the source offset plus count is greater than the size of the source file,
the

server MAY fail the operation with NFS4ERR_INVAL.or limit the area to

be copied to reflect the size of the source file.




On Fri, Feb 17, 2017 at 2:51 PM, J. Bruce Fields <[e-mail]>
wrote:

> On Thu, Feb 16, 2017 at 08:00:36AM -0500, David Noveck wrote:
> > I agree but think that the most expedient way of addressing this problem
> is
> > in the Linux client,  It can check against the file size before issuing
> the
> > COPY request  to prevent an erroneous INVAL error being returned.
>
> That doesn't work, due to races with concurrent modifications to the
> file.
>
> The server itself would seem succeptible to such races: if it implements
> the copy as a read-write loop then blocking concurrent truncates
> probably isn't reasonable, so its only choice is a short copy.  (Too
> late to return INVAL once you've written to the destination....).
>
> I really think the spec's just wrong here.
>
> --b.
>