From: Trond Myklebust <trond.myklebust@primarydata.com>
To: Jeff Layton <jeff.layton@primarydata.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Olga Kornievskaia <aglo@umich.edu>,
linux-nfs <linux-nfs@vger.kernel.org>,
Thomas Haynes <thomas.haynes@primarydata.com>
Subject: Re: how to properly handle failures during delegation recall process
Date: Wed, 5 Nov 2014 15:06:48 -0500 [thread overview]
Message-ID: <CAHQdGtSxoLwLn--9xjY7tKuTYjLL=R1Ezkp=5_-XzfUFgvtk2g@mail.gmail.com> (raw)
In-Reply-To: <20141105144251.725816f6@tlielax.poochiereds.net>
On Wed, Nov 5, 2014 at 2:42 PM, Jeff Layton <jeff.layton@primarydata.com> wrote:
> On Wed, 5 Nov 2014 13:31:52 -0500
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>> Oops, right, except for the case where the delegation's revoked just
>> because the client ran out of time doing the recall. In which case I
>> think the final error's going to be either EXPIRED (4.0) or
>> DELEG_REVOKED (4.1)? (Except I think the Linux server's returning
>> BAD_STATEID in the 4.0 case, which looks wrong.)
>>
>
> I'm not sure that that's right... RFC3530 says:
>
> NFS4ERR_EXPIRED A lease has expired that is being used in the
> current operation.
>
> ...implicit in the scenario I layed out above is that the lease is
> being maintained. It's just that the client failed to return the
> delegation in time. So, BAD_STATEID may be correct, actually?
NFS4ERR_ADMIN_REVOKED is the expected error, but that requires the
server to keep the stateid around for a while (which is why NFSv4.1
added the FREE_STATEID requirement). NFS4ERR_BAD_STATEID will work in
a pinch...
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com
next prev parent reply other threads:[~2014-11-05 20:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-13 18:51 how to properly handle failures during delegation recall process Olga Kornievskaia
2014-10-13 19:53 ` Trond Myklebust
2014-10-13 20:23 ` Olga Kornievskaia
2014-10-13 21:12 ` Trond Myklebust
2014-10-13 21:29 ` Trond Myklebust
2014-10-13 22:13 ` Olga Kornievskaia
2014-10-13 22:24 ` Trond Myklebust
2014-10-14 15:48 ` Olga Kornievskaia
2014-10-16 18:43 ` Olga Kornievskaia
2014-10-21 18:22 ` Olga Kornievskaia
2014-11-05 11:57 ` Jeff Layton
2014-11-05 12:41 ` Trond Myklebust
2014-11-05 18:31 ` J. Bruce Fields
2014-11-05 19:42 ` Jeff Layton
2014-11-05 19:54 ` J. Bruce Fields
2014-11-05 20:06 ` Jeff Layton
2014-11-05 20:13 ` J. Bruce Fields
2014-11-05 20:06 ` Trond Myklebust [this message]
2016-04-25 20:03 ` Olga Kornievskaia
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='CAHQdGtSxoLwLn--9xjY7tKuTYjLL=R1Ezkp=5_-XzfUFgvtk2g@mail.gmail.com' \
--to=trond.myklebust@primarydata.com \
--cc=aglo@umich.edu \
--cc=bfields@fieldses.org \
--cc=jeff.layton@primarydata.com \
--cc=linux-nfs@vger.kernel.org \
--cc=thomas.haynes@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.