Hi Yan,
Good morning.
Is this version okay for you ？
Addtional info:
The ceph_reclaim_caps_nr will be called with the parameter "nr" == 1 or
2 for now and a larger count in future for some cases. The old code just
assumed that "nr==1". So in corner case we may skip it many times
leaving large amount of cap reclaim pending in short time.
Thanks
BRs
On 2019/11/26 20:32, xiubli@xxxxxxxxxx wrote:
From: Xiubo Li <xiubli@xxxxxxxxxx>
The nr in ceph_reclaim_caps_nr() is very possibly larger than 1,
so we may miss it and the reclaim work couldn't triggered as expected.
Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
---
V2:
- use a more graceful test.
fs/ceph/mds_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
index 2c92a1452876..109ec7e2ee7b 100644
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -2020,7 +2020,7 @@ void ceph_reclaim_caps_nr(struct ceph_mds_client *mdsc, int nr)
if (!nr)
return;
val = atomic_add_return(nr, &mdsc->cap_reclaim_pending);
- if (!(val % CEPH_CAPS_PER_RELEASE)) {
+ if ((val % CEPH_CAPS_PER_RELEASE) < nr) {
atomic_set(&mdsc->cap_reclaim_pending, 0);
ceph_queue_cap_reclaim_work(mdsc);
}
