On Wed, 2017-02-15 at 18:36 +0800, Kinglong Mee wrote:
> On 2/15/2017 04:07, Mora, Jorge wrote:
> > Hello,
> >
> > The NFSv4.2 spec (RFC 7862) on section 15.2.3 (COPY description)
> > says the following:
> >
> > If the source offset or the source offset plus count is greater
> > than
> > the size of the source file, the operation MUST fail with
> > NFS4ERR_INVAL.
> >
> > I can understand failing with NFS4ERR_INVAL when the source offset
> > is beyond the end of the file,
>
> Yes, that's right.
>
> > but do you think failing with NFS4ERR_INVAL is too strict when the
> > source offset plus the count is beyond the end of the file?
> > What is the rationalization for failing on this specific instance?
> > Why not return a short copy instead?
>
> The man-pages of copy_file_range description as,
>
> EINVAL Requested range extends beyond the end of
> the source file; or
> the flags argument is not 0.
>
> So, the specific instance you said isn't allowed.
>
> > Can the COPY return a count less than what it requested (a short
> > copy)?
>
> Yes, the return value of copy_file_range is,
>
> RETURN VALUE
> Upon successful completion, copy_file_range() will return the
> number of
> bytes copied between files. This could be less than the
> length origi‐
> nally requested.
>
It's a valid question, though. Not least because copy_file_range() is
not guaranteed to be atomic, meaning that you could have races where
the execution of the copy_file_range() is started, but the file is
truncated when the copy is only half-complete.
Jorge, I suggest raising the question on the IETF mailing list. This
might be a candidate for a NFSv4.2 protocol errata.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
