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@redhat.com>