From 7da45d65be36d36b880cc55c5036e96c24b53f00 Mon Sep 17 00:00:00 2001 From: Qiaowei Ren Date: Thu, 1 Mar 2018 14:38:11 +0800 Subject: remove ceph code This patch removes initial ceph code, due to license issue. Change-Id: I092d44f601cdf34aed92300fe13214925563081c Signed-off-by: Qiaowei Ren --- src/ceph/doc/dev/kernel-client-troubleshooting.rst | 17 ----------------- 1 file changed, 17 deletions(-) delete mode 100644 src/ceph/doc/dev/kernel-client-troubleshooting.rst (limited to 'src/ceph/doc/dev/kernel-client-troubleshooting.rst') 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. -- cgit 1.2.3-korg