doc: correcting typos in bluestore-config-ref and bluestore-migration

Signed-off-by: Katie Holly <git@meo.ws>

diff --git a/doc/rados/configuration/bluestore-config-ref.rst b/doc/rados/configuration/bluestore-config-ref.rst
index e3b60e0ab68b53ea48b37e7f681cb8897c43d85d..2f7550a4458e3d9f9b138cd97794b2f15dc8f8d5 100644 (file)
--- a/doc/rados/configuration/bluestore-config-ref.rst
+++ b/doc/rados/configuration/bluestore-config-ref.rst
@@ -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.

diff --git a/doc/rados/operations/bluestore-migration.rst b/doc/rados/operations/bluestore-migration.rst
index d74c0d6f5168d915535ac6d5b880d3fc66410835..e0d56d8a23886600949fb8f86ff40e398cb2cd2f 100644 (file)
--- a/doc/rados/operations/bluestore-migration.rst
+++ b/doc/rados/operations/bluestore-migration.rst
@@ -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