From 1611dfbf1758149976c0f148c918bb197a018ddb Mon Sep 17 00:00:00 2001 From: Vikhyat Umrao Date: Mon, 28 Mar 2016 12:57:04 +0530 Subject: [PATCH] doc: Remove Ceph Monitors do lots of fsync() and change the ligature of "fl" to "f" and "l" Fixes: #15288 Signed-off-by: Vikhyat Umrao --- doc/rados/configuration/mon-config-ref.rst | 6 ++++-- doc/rados/operations/crush-map.rst | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/doc/rados/configuration/mon-config-ref.rst b/doc/rados/configuration/mon-config-ref.rst index 1eb9cea322f79..d4658cc6e4515 100644 --- a/doc/rados/configuration/mon-config-ref.rst +++ b/doc/rados/configuration/mon-config-ref.rst @@ -286,8 +286,10 @@ Data Ceph provides a default path where Ceph Monitors store data. For optimal performance in a production Ceph Storage Cluster, we recommend running Ceph -Monitors on separate hosts and drives from Ceph OSD Daemons. Ceph Monitors do -lots of ``fsync()``, which can interfere with Ceph OSD Daemon workloads. +Monitors on separate hosts and drives from Ceph OSD Daemons. As leveldb is using +``mmap()`` for writing the data, Ceph Monitors flush their data from memory to disk +very often, which can interfere with Ceph OSD Daemon workloads if the data +store is co-located with the OSD Daemons. In Ceph versions 0.58 and earlier, Ceph Monitors store their data in files. This approach allows users to inspect monitor data with common tools like ``ls`` diff --git a/doc/rados/operations/crush-map.rst b/doc/rados/operations/crush-map.rst index 9de08cb2cdb9f..df7ee62415923 100644 --- a/doc/rados/operations/crush-map.rst +++ b/doc/rados/operations/crush-map.rst @@ -17,7 +17,7 @@ cluster. For a detailed discussion of CRUSH, see CRUSH maps contain a list of :abbr:`OSDs (Object Storage Devices)`, a list of 'buckets' for aggregating the devices into physical locations, and a list of rules that tell CRUSH how it should replicate data in a Ceph cluster's pools. By -reflecting the underlying physical organization of the installation, CRUSH can +reflecting the underlying physical organization of the installation, CRUSH can model—and thereby address—potential sources of correlated device failures. Typical sources include physical proximity, a shared power source, and a shared network. By encoding this information into the cluster map, CRUSH placement -- 2.39.5