问题：
HEALTH_WARN mds0: Client localhost:guest failing to respond to capability release
ceph版本：10.2.11
解决方法：
https://tracker.ceph.com/issues/18798
也就是说目前最好是把linux大于4.9的内核合并到当前代码;
临时规避的方法就是设置mds_cache_size的大小。
mds_cache_size * 4K < 内存大小
但是！！！！！！！！！
亲自测试的结果显示，我遇到的这个问题跟mds_cache_size这个值毫无关系。
把mds_cache_size调大，还是会出现上述问题，调小也不是必然出现上述问题。
可能我遇到的情况只是产生这个结果的原因之一。
也不用怀疑我配置错了，我是在配置文件里改了之后，然后重启的ceph-mds,然后用
ceph daemon mds.node1 config show | grep mds_cache_size
查询都证明通过了的。而且调小之后，通过
cat /sys/kernel/debug/ceph/32d16445-997c-4f06-b9a6-00153dcc9593.client3074583/caps
查看，发现客户端好像并没有受到mds_cache_size的限制。浏览了多个目录之后，值可以远超mds_cache_size限制的值。
现在此问题的定位已经陷入僵局。
参考的网址：
https://tracker.ceph.com/issues/11482
https://blog.csdn.net/zhaominpro/article/details/101761394
https://ceph-users.ceph.narkive.com/8cpL6ibq/cephfs-ceph-fuse-mds0-client-xxx-xxx-failing-to-respond-to-capability-release
https://peteryj.github.io/2020/04/29/cephfs-debug-intro/
客户端对能力的英文描述(原文)
/*
* Capability management
*
* The Ceph metadata servers control client access to inode metadata
* and file data by issuing capabilities, granting clients permission
* to read and/or write both inode field and file data to OSDs
* (storage nodes). Each capability consists of a set of bits
* indicating which operations are allowed.
*
* If the client holds a *_SHARED cap, the client has a coherent value
* that can be safely read from the cached inode.
*
* In the case of a *_EXCL (exclusive) or FILE_WR capabilities, the
* client is allowed to change inode attributes (e.g., file size,
* mtime), note its dirty state in the ceph_cap, and asynchronously
* flush that metadata change to the MDS.
*
* In the event of a conflicting operation (perhaps by another
* client), the MDS will revoke the conflicting client capabilities.
*
* In order for a client to cache an inode, it must hold a capability
* with at least one MDS server. When inodes are released, release
* notifications are batched and periodically sent en masse to the MDS
* cluster to release server state.
*/
