From: Zac Dover Date: Tue, 3 Aug 2021 16:25:14 +0000 (+1000) Subject: doc/rados: rewrite BlueStore material X-Git-Tag: v17.1.0~1202^2 X-Git-Url: http://git.apps.os.sepia.ceph.com/?a=commitdiff_plain;h=d604b2e67abf62d52c31b80477ee727b98af9cee;p=ceph-ci.git doc/rados: rewrite BlueStore material This PR improves the English text explaining the BlueStore filesystem backend. Signed-off-by: Zac Dover --- diff --git a/doc/rados/configuration/storage-devices.rst b/doc/rados/configuration/storage-devices.rst index e2526677867..da679d4425d 100644 --- a/doc/rados/configuration/storage-devices.rst +++ b/doc/rados/configuration/storage-devices.rst @@ -31,33 +31,34 @@ with the Luminous 12.2.z release, the new default (and recommended) backend is BlueStore --------- -BlueStore is a special-purpose storage backend designed specifically -for managing data on disk for Ceph OSD workloads. It is motivated by -experience supporting and managing OSDs using FileStore over the -last ten years. Key BlueStore features include: +BlueStore is a special-purpose storage backend designed specifically for +managing data on disk for Ceph OSD workloads. BlueStore is based on over a +decade of experience supporting and managing OSDs using FileStore. -* Direct management of storage devices. BlueStore consumes raw block - devices or partitions. This avoids any intervening layers of - abstraction (such as local file systems like XFS) that may limit +Key BlueStore features include: + +* Direct management of storage devices. BlueStore consumes raw block + devices or partitions. This avoids intervening layers of + abstraction (such as local file systems like XFS) that can limit performance or add complexity. -* Metadata management with RocksDB. We embed RocksDB's key/value database - in order to manage internal metadata, such as the mapping from object +* Metadata management with RocksDB. RocksDB's key/value database is embedded + in order to manage internal metadata, including the mapping of object names to block locations on disk. -* Full data and metadata checksumming. By default all data and +* Full data and metadata checksumming. By default, all data and metadata written to BlueStore is protected by one or more - checksums. No data or metadata will be read from disk or returned + checksums. No data or metadata is read from disk or returned to the user without being verified. -* Inline compression. Data written may be optionally compressed - before being written to disk. -* Multi-device metadata tiering. BlueStore allows its internal +* Inline compression. Data can be optionally compressed before being written + to disk. +* Multi-device metadata tiering. BlueStore allows its internal journal (write-ahead log) to be written to a separate, high-speed - device (like an SSD, NVMe, or NVDIMM) to increased performance. If + device (like an SSD, NVMe, or NVDIMM) for increased performance. If a significant amount of faster storage is available, internal - metadata can also be stored on the faster device. -* Efficient copy-on-write. RBD and CephFS snapshots rely on a + metadata can be stored on the faster device. +* Efficient copy-on-write. RBD and CephFS snapshots rely on a copy-on-write *clone* mechanism that is implemented efficiently in - BlueStore. This results in efficient IO both for regular snapshots - and for erasure coded pools (which rely on cloning to implement + BlueStore. This results in efficient I/O both for regular snapshots + and for erasure-coded pools (which rely on cloning to implement efficient two-phase commits). For more information, see :doc:`bluestore-config-ref` and :doc:`/rados/operations/bluestore-migration`.