initial code repo

This patch creates initial code repo.

For ceph, luminous stable release will be used for base code,
and next changes and optimization for ceph will be added to it.

For opensds, currently any changes can be upstreamed into original
opensds repo (https://github.com/opensds/opensds), and so stor4nfv
will directly clone opensds code to deploy stor4nfv environment.
And the scripts for deployment based on ceph and opensds will be
put into 'ci' directory.

Change-Id: I46a32218884c75dda2936337604ff03c554648e4
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>

1 files changed, 17 insertions, 0 deletions

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