On Thu, Apr 28, 2022 at 11:42 PM Xiubo Li <xiubli@xxxxxxxxxx> wrote:
>
> For example if the Frwcb caps are being revoked, but only the Fr
> caps is still being used then the kclient will skip releasing them
> all. But in next turn if the Fr caps is ready to be released the
> Fw caps maybe just being used again. So in corner case, such as
> heavy load IOs, the revocation maybe stuck for a long time.
>
This does not make sense. If Frwcb are being revoked, writer can't get
Fw again. Second, Frwcb are managed by single lock at mds side.
Partial releasing caps does make lock state transition possible.
> Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
> ---
> fs/ceph/caps.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> index 0c0c8f5ae3b3..7eb5238941fc 100644
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -1947,6 +1947,13 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
>
> /* The ones we currently want to retain (may be adjusted below) */
> retain = file_wanted | used | CEPH_CAP_PIN;
> +
> + /*
> + * Do not retain the capabilities if they are under revoking
> + * but not used, this could help speed up the revoking.
> + */
> + retain &= ~((revoking & retain) & ~used);
> +
> if (!mdsc->stopping && inode->i_nlink > 0) {
> if (file_wanted) {
> retain |= CEPH_CAP_ANY; /* be greedy */
> --
> 2.36.0.rc1
>
