From: "bfields@fieldses.org" <bfields@fieldses.org>
To: Trond Myklebust <trondmy@primarydata.com>
Cc: Thomas Haynes <loghyr@primarydata.com>,
"loghyr@excfb.com" <loghyr@excfb.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: pynfs replay cache test SEQ9f
Date: Fri, 13 Oct 2017 16:19:23 -0400 [thread overview]
Message-ID: <20171013201923.GA16149@fieldses.org> (raw)
In-Reply-To: <20171013185015.GA15087@fieldses.org>
On Fri, Oct 13, 2017 at 02:50:15PM -0400, bfields@fieldses.org wrote:
> Those all involve uncached compounds with more than one op. My reading
> of knfsd code is that it will return RETRY_UNCACHED_REP in this case,
> and I think (I might be misunderstanding) that the client will bump the
> slot seqid and retry in that case. So I *think* you shouldn't be seeing
> that problem with knfsd?
So to bring it back to the original question, I'm still not sure it's
actually a problem if a server returns NFS_OK when cache_this is set
differently betwen two compound calls each containing just a single
SEQUENCE.
But, maybe it's worth at least warning about.
--b.
next prev parent reply other threads:[~2017-10-13 20:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 16:48 [PATCH] Args need to be the same for replay cache Thomas Haynes
2017-10-12 18:32 ` pynfs replay cache test SEQ9f Thomas Haynes
2017-10-12 19:30 ` Trond Myklebust
2017-10-12 19:49 ` J. Bruce Fields
2017-10-12 21:39 ` [nfsv4] " Thomas Haynes
2017-10-12 21:44 ` J. Bruce Fields
2017-10-12 22:00 ` Tom Haynes
2017-10-13 1:52 ` J. Bruce Fields
2017-10-13 13:34 ` Trond Myklebust
2017-10-13 15:00 ` bfields
2017-10-13 15:26 ` Trond Myklebust
2017-10-13 18:50 ` bfields
2017-10-13 20:19 ` bfields [this message]
2017-10-17 21:31 ` bfields
2017-10-16 16:15 ` [nfsv4] " Frank Filz
2018-04-10 19:49 ` [PATCH] Args need to be the same for replay cache J. Bruce Fields
2018-04-24 20:10 ` Olga Kornievskaia
2018-04-24 22:16 ` 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=20171013201923.GA16149@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=loghyr@excfb.com \
--cc=loghyr@primarydata.com \
--cc=nfsv4@ietf.org \
--cc=trondmy@primarydata.com \
/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.