mirror of
https://github.com/ceph/ceph
synced 2025-01-29 22:43:40 +00:00
doc: drop kernel-client-troubleshooting.rst
Signed-off-by: Jos Collin <jcollin@redhat.com>
This commit is contained in:
parent
20aa4ac783
commit
cf08a98523
@ -1,21 +0,0 @@
|
||||
====================================
|
||||
Kernel client troubleshooting (FS)
|
||||
====================================
|
||||
|
||||
If there is an issue with the cephfs kernel client, the most important thing is
|
||||
figuring out whether the problem is with the client or the MDS. Generally,
|
||||
this is easy to work out. If the kernel client broke directly, there
|
||||
will be output in dmesg. Collect it and any appropriate kernel state. If
|
||||
the problem is with the MDS, there will be hung requests that the client
|
||||
is waiting on. Look in ``/sys/kernel/debug/ceph/*/`` and cat the ``mdsc`` file to get a listing of requests in progress. If one of them remains there, the
|
||||
MDS has probably "forgotten" it.
|
||||
We can get hints about what's going on by dumping the MDS cache:
|
||||
ceph mds tell 0 dumpcache /tmp/dump.txt
|
||||
|
||||
And if high logging levels are set on the MDS, that will almost certainly
|
||||
hold the information we need to diagnose and solve the issue.
|
||||
|
||||
You can also enable dynamic debug against the cephfs module.
|
||||
|
||||
See:
|
||||
https://github.com/ceph/ceph/blob/master/src/script/kcon_all.sh
|
Loading…
Reference in New Issue
Block a user