ceph-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: ceph-devel@vger.kernel.org
Cc: idryomov@gmail.com, ukernel@gmail.com, pdonnell@redhat.com
Subject: [PATCH v4 0/5] ceph: fix spurious recover_session=clean errors
Date: Wed,  7 Oct 2020 08:16:55 -0400	[thread overview]
Message-ID: <20201007121700.10489-1-jlayton@kernel.org> (raw)

v4: test for CEPH_MOUNT_RECOVER in more places
v3: add RECOVER mount_state and allow dumping pagecache when it's set
    shrink size of mount_state field
v2: fix handling of async requests in patch to queue requests

This is the fourth revision of this patchset. The main difference from
v3 is that this one converts more "==" tests for SHUTDOWN state into
">=", so that the RECOVER state is treated the same way.

Original cover letter:

Ilya noticed that he would get spurious EACCES errors on calls done just
after blocklisting the client on mounts with recover_session=clean. The
session would get marked as REJECTED and that caused in-flight calls to
die with EACCES. This patchset seems to smooth over the problem, but I'm
not fully convinced it's the right approach.

The potential issue I see is that the client could take cap references to
do a call on a session that has been blocklisted. We then queue the
message and reestablish the session, but we may not have been granted
the same caps by the MDS at that point.

If this is a problem, then we probably need to rework it so that we
return a distinct error code in this situation and have the upper layers
issue a completely new mds request (with new cap refs, etc.)

Obviously, that's a much more invasive approach though, so it would be
nice to avoid that if this would suffice.

Jeff Layton (5):
  ceph: don't WARN when removing caps due to blocklisting
  ceph: make fsc->mount_state an int
  ceph: add new RECOVER mount_state when recovering session
  ceph: remove timeout on allowing reconnect after blocklisting
  ceph: queue MDS requests to REJECTED sessions when CLEANRECOVER is set

 fs/ceph/addr.c               |  4 ++--
 fs/ceph/caps.c               |  4 ++--
 fs/ceph/inode.c              |  2 +-
 fs/ceph/mds_client.c         | 27 ++++++++++++++++-----------
 fs/ceph/super.c              | 14 ++++++++++----
 fs/ceph/super.h              |  3 +--
 include/linux/ceph/libceph.h |  1 +
 7 files changed, 33 insertions(+), 22 deletions(-)

-- 
2.26.2


             reply	other threads:[~2020-10-07 12:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 12:16 Jeff Layton [this message]
2020-10-07 12:16 ` [PATCH v4 1/5] ceph: don't WARN when removing caps due to blocklisting Jeff Layton
2020-10-07 12:16 ` [PATCH v4 2/5] ceph: make fsc->mount_state an int Jeff Layton
2020-10-07 12:16 ` [PATCH v4 3/5] ceph: add new RECOVER mount_state when recovering session Jeff Layton
2020-10-07 12:16 ` [PATCH v4 4/5] ceph: remove timeout on allowing reconnect after blocklisting Jeff Layton
2020-10-07 12:17 ` [PATCH v4 5/5] ceph: queue MDS requests to REJECTED sessions when CLEANRECOVER is set Jeff Layton
2020-10-20  7:03 ` [PATCH v4 0/5] ceph: fix spurious recover_session=clean errors Xiubo Li
2020-10-21 13:51 ` Yan, Zheng

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=20201007121700.10489-1-jlayton@kernel.org \
    --to=jlayton@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=pdonnell@redhat.com \
    --cc=ukernel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).