Before resorting to a measure as drastic as this, it is a good idea to try less
drastic measures and then assess if the file system experience has improved due
to it. One example of such less drastic measure is to disable asynchronous
-threads launched by volumes plugins for cloning and purging trash.
+threads launched by volumes plugins for cloning and purging trash. For details
+on these see: :ref:`pause-purge-threads` and :ref:`pause-clone-threads`.
.. _manila: https://github.com/openstack/manila
That prevents any clients from establishing new sessions with the MDS.
+* **Dont tweak max_mds** Modifying the FS setting variable ``max_mds`` is
+ sometimes perceived as a good step during troubleshooting or recovery effort.
+ Instead, doing so might further destabilize the cluster. If ``max_mds`` must
+ be changed in such circumstances, run the command to change ``max_mds`` with
+ the confirmation flag (``--yes-i-really-mean-it``)
+
+.. _pause-purge-threads:
+* **Turn off async purge threads** The volumes plugin spawns threads for
+ asynchronously purging trashed/deleted subvolumes. To help troubleshooting or
+ recovery effort, these purge threads can be disabled using:
+
+.. code:: bash
+
+ ceph config set mgr mgr/volumes/pause_purging true
+
+ To resume purging run::
+
+ ceph config set mgr mgr/volumes/pause_purging false
+
+.. _pause-clone-threads:
+* **Turn off async cloner threads** The volumes plugin spawns threads for
+ asynchronously cloning subvolume snapshots. To help troubleshooting or
+ recovery effort, these cloner threads can be disabled using:
+
+.. code:: bash
+
+ ceph config set mgr mgr/volumes/pause_cloning true
+
+ To resume cloning run::
+
+ ceph config set mgr mgr/volumes/pause_cloning false
+
Expediting MDS journal trim