Skip to content

Commit edb3d2b

Browse files
committed
doc/cephfs: edit troubleshooting.rst
Edit the section "Slow Requests (MDS)" in doc/cephfs/troubleshooting.rst. Signed-off-by: Zac Dover <[email protected]>
1 parent a78281e commit edb3d2b

File tree

1 file changed

+21
-15
lines changed

1 file changed

+21
-15
lines changed

doc/cephfs/troubleshooting.rst

Lines changed: 21 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -244,24 +244,30 @@ the developers!
244244

245245
Slow requests (MDS)
246246
-------------------
247-
You can list current operations via the admin socket by running::
247+
List current operations via the admin socket by running the following command
248+
from the MDS host:
248249

249-
ceph daemon mds.<name> dump_ops_in_flight
250+
.. prompt:: bash #
251+
252+
ceph daemon mds.<name> dump_ops_in_flight
250253

251-
from the MDS host. Identify the stuck commands and examine why they are stuck.
254+
Identify the stuck commands and examine why they are stuck.
252255
Usually the last "event" will have been an attempt to gather locks, or sending
253-
the operation off to the MDS log. If it is waiting on the OSDs, fix them. If
254-
operations are stuck on a specific inode, you probably have a client holding
255-
caps which prevent others from using it, either because the client is trying
256-
to flush out dirty data or because you have encountered a bug in CephFS'
257-
distributed file lock code (the file "capabilities" ["caps"] system).
258-
259-
If it's a result of a bug in the capabilities code, restarting the MDS
260-
is likely to resolve the problem.
261-
262-
If there are no slow requests reported on the MDS, and it is not reporting
263-
that clients are misbehaving, either the client has a problem or its
264-
requests are not reaching the MDS.
256+
the operation off to the MDS log. If it is waiting on the OSDs, fix them.
257+
258+
If operations are stuck on a specific inode, then a client is likely holding
259+
capabilities, preventing its use by other clients. This situation can be caused
260+
by a client trying to flush dirty data, but it might be caused because you have
261+
encountered a bug in the distributed file lock code (the file "capabilities"
262+
["caps"] system) of CephFS.
263+
264+
If you have determined that the commands are stuck because of a bug in the
265+
capabilities code, restart the MDS. Restarting the MDS is likely to resolve the
266+
problem.
267+
268+
If there are no slow requests reported on the MDS, and there is no indication
269+
that clients are misbehaving, then either there is a problem with the client
270+
or the client's requests are not reaching the MDS.
265271

266272
.. _ceph_fuse_debugging:
267273

0 commit comments

Comments
 (0)