From 483eb2f56657e8e7f419ab1a4fab8dce9ade8609 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 20:24:20 +0200 Subject: Adding upstream version 14.2.21. Signed-off-by: Daniel Baumann --- doc/dev/kernel-client-troubleshooting.rst | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 doc/dev/kernel-client-troubleshooting.rst (limited to 'doc/dev/kernel-client-troubleshooting.rst') diff --git a/doc/dev/kernel-client-troubleshooting.rst b/doc/dev/kernel-client-troubleshooting.rst new file mode 100644 index 00000000..b6f7eff7 --- /dev/null +++ b/doc/dev/kernel-client-troubleshooting.rst @@ -0,0 +1,21 @@ +==================================== + 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 -- cgit v1.2.3