From: "J. Bruce Fields" <bfields@fieldses.org>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: "Kornievskaia, Olga" <Olga.Kornievskaia@netapp.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: NFSv4.2 server replies to Copy with length == 0
Date: Thu, 17 Oct 2019 10:49:21 -0400 [thread overview]
Message-ID: <20191017144921.GF32141@fieldses.org> (raw)
In-Reply-To: <YQBPR0101MB16526D76EE6A574D31EDF9DBDD6D0@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
On Thu, Oct 17, 2019 at 04:43:58AM +0000, Rick Macklem wrote:
> >>On Wed, Oct 16, 2019 at 07:53:45PM +0000, Kornievskaia, Olga wrote:
> >>> On the client if VFS did read of len=0 then VFS itself we return 0,
> >>> thus this doesn't protect against other clients sending an NFS copy
> >>> with len=0. And in NFS, receiving copy with len=0 means copy to the
> >>> end of the file. It's not implemented for any "intra" or "inter" code.
> >Are you saying that an NFSv4.2 Copy request with a ca_count == 0
> >will not work for the Linux NFSv4.2 server?
> >(I guess I'd better test this one, too.)
> Tested it and it does not work, at least for Fedora30.
> The server just returns 0 instead of doing a copy to EOF on the input file.
> I think you should implement this, although my client does not do this now.
Agreed.
--b.
next prev parent reply other threads:[~2019-10-17 14:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 2:50 NFSv4.2 server replies to Copy with length == 0 Rick Macklem
2019-10-16 6:22 ` Rick Macklem
2019-10-16 15:58 ` J. Bruce Fields
2019-10-16 19:53 ` Kornievskaia, Olga
2019-10-16 20:31 ` J. Bruce Fields
2019-10-17 2:16 ` Rick Macklem
2019-10-17 4:43 ` Rick Macklem
2019-10-17 14:49 ` J. Bruce Fields [this message]
2019-10-17 15:22 ` J. Bruce Fields
2019-10-17 15:39 ` Tom Talpey
2019-10-17 16:20 ` Rick Macklem
2019-10-17 17:15 ` [nfsv4] " Olga Kornievskaia
2019-10-17 21:34 ` Rick Macklem
2019-10-17 15:55 ` Rick Macklem
2019-10-17 16:14 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191017144921.GF32141@fieldses.org \
--to=bfields@fieldses.org \
--cc=Olga.Kornievskaia@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@ietf.org \
--cc=rmacklem@uoguelph.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.