]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commitdiff
doc: correcting typos in bluestore-config-ref and bluestore-migration
authorKatie Holly <git@meo.ws>
Sun, 26 Nov 2017 16:47:35 +0000 (17:47 +0100)
committerAlfredo Deza <adeza@redhat.com>
Fri, 2 Mar 2018 15:18:26 +0000 (10:18 -0500)
Signed-off-by: Katie Holly <git@meo.ws>
(cherry picked from commit 40e20986cddddb6bea13905a66a8b1fa554af21f)

doc/rados/configuration/bluestore-config-ref.rst
doc/rados/operations/bluestore-migration.rst

index 8d8ace653c459b21a14c6a6ef421fcb967cc7f67..542ba151a1cb46c317b30e10f4a0362874f4aaa9 100644 (file)
@@ -14,7 +14,7 @@ device.  The storage device is normally partitioned into two parts:
 #. A small partition is formatted with XFS and contains basic metadata
    for the OSD.  This *data directory* includes information about the
    OSD (its identifier, which cluster it belongs to, and its private
-   keyring.
+   keyring).
 
 #. The rest of the device is normally a large partition occupying the
    rest of the device that is managed directly by BlueStore contains
@@ -143,8 +143,8 @@ value (usually 4 bytes) for every 4 kilobyte block of data.
 It is possible to use a smaller checksum value by truncating the
 checksum to two or one byte, reducing the metadata overhead.  The
 trade-off is that the probability that a random error will not be
-detected is higher with a smaller checksum, going from about one if
-four billion with a 32-bit (4 byte) checksum to one is 65,536 for a
+detected is higher with a smaller checksum, going from about one in
+four billion with a 32-bit (4 byte) checksum to one in 65,536 for a
 16-bit (2 byte) checksum or one in 256 for an 8-bit (1 byte) checksum.
 The smaller checksum values can be used by selecting `crc32c_16` or
 `crc32c_8` as the checksum algorithm.
index d74c0d6f5168d915535ac6d5b880d3fc66410835..e0d56d8a23886600949fb8f86ff40e398cb2cd2f 100644 (file)
@@ -12,7 +12,7 @@ An individual OSD cannot be converted in place in isolation, however:
 BlueStore and FileStore are simply too different for that to be
 practical.  "Conversion" will rely either on the cluster's normal
 replication and healing support or tools and strategies that copy OSD
-content from and old (FileStore) device to a new (BlueStore) one.
+content from an old (FileStore) device to a new (BlueStore) one.
 
 
 Deploy new OSDs with BlueStore