From: bfields@fieldses.org (J. Bruce Fields)
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Olga Kornievskaia <kolga@netapp.com>
Subject: Re: NFSv4.2 server replies to Copy with length == 0
Date: Wed, 16 Oct 2019 11:58:38 -0400 [thread overview]
Message-ID: <20191016155838.GA17543@fieldses.org> (raw)
In-Reply-To: <YQBPR0101MB1652DEF8AD7A6169D44D47C6DD920@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
On Wed, Oct 16, 2019 at 06:22:42AM +0000, Rick Macklem wrote:
> It seems that the Copy reply with wr_count == 0 occurs when the client
> sends a Copy request with ca_src_offset beyond EOF in the input file.
> (It happened because I was testing an old/broken version of my client,
> but I can reproduce it, if you need a bugfix to be tested. I don't know if
> the case of ca_src_offset+ca_count beyond EOF behaves the same?)
> --> The RFC seems to require a reply of NFS4ERR_INVAL for this case.
I've never understood that INVAL requirement. But I know it's been
discussed before, maybe there was some justification for it that I've
forgotten.
--b.
>
> rick
>
> ________________________________________
> From: linux-nfs-owner@vger.kernel.org <linux-nfs-owner@vger.kernel.org> on behalf of Rick Macklem <rmacklem@uoguelph.ca>
> Sent: Tuesday, October 15, 2019 10:50 PM
> To: linux-nfs@vger.kernel.org
> Subject: NFSv4.2 server replies to Copy with length == 0
>
> During interop testing (FreeBSD client->Linux server) of NFSv4.2, my
> client got into a loop. It was because the reply to Copy was NFS_OK,
> but the length in the reply is 0.
> (I'll fix the client to fail for this case so it doesn't loop, but...)
>
> The server is Fedora 30 (5.2.18-200 kernel version).
> It you think this might be fixed in a newer kernel or you'd like me to do
> something with it to get more info, just let me know.
>
> I've attached a snippet of the packet trace. (If the list strips it off, just email
> me and I'll send it to you.)
>
> rick
next prev parent reply other threads:[~2019-10-16 15:58 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 [this message]
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
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=20191016155838.GA17543@fieldses.org \
--to=bfields@fieldses.org \
--cc=kolga@netapp.com \
--cc=linux-nfs@vger.kernel.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.