]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/configuration: edit "bg" in mon-config-ref.rst 53347/head
authorZac Dover <zac.dover@proton.me>
Fri, 8 Sep 2023 11:53:51 +0000 (21:53 +1000)
committerZac Dover <zac.dover@proton.me>
Sat, 9 Sep 2023 01:56:55 +0000 (11:56 +1000)
Edit the English in the section "Background" in
doc/rados/configuration/mon-config-ref.rst.

Signed-off-by: Zac Dover <zac.dover@proton.me>
(cherry picked from commit d009f0757cb34cf1cc9ac107905235d1b2ac65cd)

doc/rados/configuration/mon-config-ref.rst

index c19728ada7cce858b93dbe6606a07c1d6779cae1..0eca8572d13f1ca415cb7fe156f8c669cd8045bb 100644 (file)
@@ -18,27 +18,25 @@ Background
 
 Ceph Monitors maintain a "master copy" of the :term:`Cluster Map`. 
 
-The maintenance by Ceph Monitors of a :term:`Cluster Map` makes it possible for
-a :term:`Ceph Client` to determine the location of all Ceph Monitors, Ceph OSD
-Daemons, and Ceph Metadata Servers by connecting to one Ceph Monitor and
-retrieving a current cluster map. Before Ceph Clients can read from or write to
-Ceph OSD Daemons or Ceph Metadata Servers, they must connect to a Ceph Monitor.
-When a Ceph client has a current copy of the cluster map and the CRUSH
-algorithm, it can compute the location for any RADOS object within in the
-cluster. This ability to compute the locations of objects makes it possible for
-Ceph Clients to talk directly to Ceph OSD Daemons. This direct communication
-with Ceph OSD Daemons represents an improvment upon traditional storage
-architectures in which clients were required to communicate with a central
-component, and that improvment contributes to Ceph's high scalability and
-performance. See `Scalability and High Availability`_ for additional details.
+The :term:`Cluster Map` makes it possible for :term:`Ceph client`\s to
+determine the location of all Ceph Monitors, Ceph OSD Daemons, and Ceph
+Metadata Servers. Clients do this by connecting to one Ceph Monitor and
+retrieving a current cluster map. Ceph clients must connect to a Ceph Monitor
+before they can read from or write to Ceph OSD Daemons or Ceph Metadata
+Servers. A Ceph client that has a current copy of the cluster map and the CRUSH
+algorithm can compute the location of any RADOS object within the cluster. This
+makes it possible for Ceph clients to talk directly to Ceph OSD Daemons. Direct
+communication between clients and Ceph OSD Daemons improves upon traditional
+storage architectures that required clients to communicate with a central
+component.  See `Scalability and High Availability`_ for more on this subject.
 
 The Ceph Monitor's primary function is to maintain a master copy of the cluster
 map. Monitors also provide authentication and logging services. All changes in
 the monitor services are written by the Ceph Monitor to a single Paxos
-instance, and Paxos writes the changes to a key/value store for strong
-consistency. Ceph Monitors are able to query the most recent version of the
-cluster map during sync operations, and they use the key/value store's
-snapshots and iterators (using leveldb) to perform store-wide synchronization.
+instance, and Paxos writes the changes to a key/value store. This provides
+strong consistency. Ceph Monitors are able to query the most recent version of
+the cluster map during sync operations, and they use the key/value store's
+snapshots and iterators (using RocksDB) to perform store-wide synchronization.
 
 .. ditaa::
  /-------------\               /-------------\