X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=src%2Fceph%2Fdoc%2Fdev%2Fkernel-client-troubleshooting.rst;fp=src%2Fceph%2Fdoc%2Fdev%2Fkernel-client-troubleshooting.rst;h=0000000000000000000000000000000000000000;hb=7da45d65be36d36b880cc55c5036e96c24b53f00;hp=59e476148e5b79b50b92428cb62105a3b0646f6f;hpb=691462d09d0987b47e112d6ee8740375df3c51b2;p=stor4nfv.git

diff --git a/src/ceph/doc/dev/kernel-client-troubleshooting.rst b/src/ceph/doc/dev/kernel-client-troubleshooting.rst
deleted file mode 100644
index 59e4761..0000000
--- a/src/ceph/doc/dev/kernel-client-troubleshooting.rst
+++ /dev/null
@@ -1,17 +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.