]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/dev/kernel-client-troubleshooting: Add kernel dynamic debuggin 19142/head
authorShinobu Kinjo <shinobu@redhat.com>
Sat, 25 Nov 2017 01:22:00 +0000 (20:22 -0500)
committerShinobu Kinjo <shinobu@redhat.com>
Sat, 25 Nov 2017 01:22:00 +0000 (20:22 -0500)
Signed-off-by: Shinobu Kinjo <shinobu@redhat.com>
doc/dev/kernel-client-troubleshooting.rst

index 59e476148e5b79b50b92428cb62105a3b0646f6f..b6f7eff7beff0c758a4316b8a9bbb7943c3ce27f 100644 (file)
@@ -7,11 +7,15 @@ 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
+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