Re: [nfsv4] Server-side copy question

> 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.
> 

Could we please make that message to implementors stronger, but saying “the server SHOULD limit the are to be copied to reflect the size of the source file, but it MAY fail the operation with NFS4ERR_INVAL”?

Cheers
  Trond

> On Feb 18, 2017, at 07:45, David Noveck <davenoveck@gmail.com> 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.
> 
> 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 <bfields@fieldses.org <mailto:bfields@fieldses.org>> 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.
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4