6:10 a.m.
This:
2020-06-14 14:36:26.133 7fb5edd82700 0 log_channel(cluster) log [WRN] :
client.4022217 isn't responding to mclientcaps(revoke), ino
0x100001b9177 pending pAsLsXs issued pAsLsXsFs, sent 60.158122 seconds
ago
The client is not responding to a revoke of FILE_SHARED (Fs) caps.
We've seen similar symptoms in the past with rsync-style workloads.
Ganesha can pin a lot of inodes, which all have to be tracked on the
MDS.
That said, it looks like it's just trying to revoke Fs, so it's not 100%
clear that the new cache pressure callbacks would help this situation.
It could be that the client is not releasing Fs for some other reason.
This is an area where libcephfs has very poor visibility, unfortunately.
-- Jeff
On Wed, 2020-06-17 at 00:04 +0200, Marc Roos wrote:
Hi Jeff, how did you deduct this from the log file? I can't see
where the 'error' is.
-----Original Message-----
Subject: Re: [NFS-Ganesha-Support] bug in nfs-ganesha? and cephfs?
On Sun, 2020-06-14 at 15:17 +0200, Marc Roos wrote:
> When rsyncing to a nfs-ganesha exported cephfs the process hangs, and
> escalates into "cache pressure" of other cephfs clients[1].
>
> When testing the rsync with more debugging on, I noticed that rsync
> stalled at the 'set modtime of . '[2]
>
> After restarting the nfs-ganesha and doing a few successful ls -al on
> the nfs mount. I was able to create this 'stall' by doing only a
'touch
> /var/www/cobbler/ks_mirror/CentOS7-x86_64/' on the directory. As
> mentioned in the post[1]. The same xlock message is in the mds log[4]
> the nfs-ganesha log during this touch[5].
>
>
>
> nfs-ganesha-2.8.1.2-0.1.el7.x86_64
> nfs-ganesha-ceph-2.8.1.2-0.1.el7.x86_64
>
> ceph version 14.2.9 (581f22da52345dba46ee232b73b990f06029a2a0)
nautilus
> (stable)
>
>
--
Jeff Layton <jlayton(a)redhat.com>