From 1e8d753876e006e812a47f7398f2e887f37f4b8f Mon Sep 17 00:00:00 2001 From: Ashita Dashottar Date: Wed, 28 Mar 2018 04:12:33 +0530 Subject: [PATCH] doc: typo fix Signed-off-by: Ashita Dashottar --- doc/dev/ceph-volume/lvm.rst | 2 +- doc/dev/osd_internals/last_epoch_started.rst | 4 ++-- doc/dev/osd_internals/log_based_pg.rst | 6 +++--- doc/dev/osd_internals/pg_removal.rst | 12 ++++++------ doc/dev/osd_internals/snaps.rst | 2 +- doc/dev/osd_internals/wbthrottle.rst | 4 ++-- 6 files changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/dev/ceph-volume/lvm.rst b/doc/dev/ceph-volume/lvm.rst index ceac235cdb6..529e7e47052 100644 --- a/doc/dev/ceph-volume/lvm.rst +++ b/doc/dev/ceph-volume/lvm.rst @@ -40,7 +40,7 @@ LVM volume: ``type`` -------- -Describes if the device is a an OSD or Journal, with the ability to expand to +Describes if the device is an OSD or Journal, with the ability to expand to other types when supported (for example a lockbox) Example:: diff --git a/doc/dev/osd_internals/last_epoch_started.rst b/doc/dev/osd_internals/last_epoch_started.rst index 9978bd31c1f..586f9f7b125 100644 --- a/doc/dev/osd_internals/last_epoch_started.rst +++ b/doc/dev/osd_internals/last_epoch_started.rst @@ -3,12 +3,12 @@ last_epoch_started ====================== info.last_epoch_started records an activation epoch e for interval i -such that all writes commited in i or earlier are reflected in the +such that all writes committed in i or earlier are reflected in the local info/log and no writes after i are reflected in the local info/log. Since no committed write is ever divergent, even if we get an authoritative log/info with an older info.last_epoch_started, we can leave our info.last_epoch_started alone since no writes could -have commited in any intervening interval (See PG::proc_master_log). +have committed in any intervening interval (See PG::proc_master_log). info.history.last_epoch_started records a lower bound on the most recent interval in which the pg as a whole went active and accepted diff --git a/doc/dev/osd_internals/log_based_pg.rst b/doc/dev/osd_internals/log_based_pg.rst index 8b110122303..4f4524f8d88 100644 --- a/doc/dev/osd_internals/log_based_pg.rst +++ b/doc/dev/osd_internals/log_based_pg.rst @@ -94,7 +94,7 @@ and so many similarities #. The high level locking rules for mixing reads and writes without exposing uncommitted state (which might be rolled back or forgotten later) #. The process, metadata, and protocol needed to determine the set of osds - which partcipated in the most recent interval in which we accepted writes + which participated in the most recent interval in which we accepted writes #. etc. Instead, we choose a few abstractions (and a few kludges) to paper over the differences: @@ -126,7 +126,7 @@ Readable vs Degraded For a replicated pool, an object is readable iff it is present on the primary (at the right version). For an ec pool, we need at least M shards present to do a read, and we need it on the primary. For -this reason, PGBackend needs to include some interfaces for determing +this reason, PGBackend needs to include some interfaces for determining when recovery is required to serve a read vs a write. This also changes the rules for when peering has enough logs to prove that it @@ -142,7 +142,7 @@ Reads with the replicated strategy can always be satisfied synchronously out of the primary OSD. With an erasure coded strategy, the primary will need to request data from some number of replicas in order to satisfy a read. PGBackend will therefore need to provide -seperate objects_read_sync and objects_read_async interfaces where +separate objects_read_sync and objects_read_async interfaces where the former won't be implemented by the ECBackend. PGBackend interfaces: diff --git a/doc/dev/osd_internals/pg_removal.rst b/doc/dev/osd_internals/pg_removal.rst index d968eccc631..c5fe0e1ab47 100644 --- a/doc/dev/osd_internals/pg_removal.rst +++ b/doc/dev/osd_internals/pg_removal.rst @@ -11,7 +11,7 @@ There are two ways for a pg to be removed from an OSD: In either case, our general strategy for removing the pg is to atomically set the metadata objects (pg->log_oid, pg->biginfo_oid) to -backfill and asynronously remove the pg collections. We do not do +backfill and asynchronously remove the pg collections. We do not do this inline because scanning the collections to remove the objects is an expensive operation. @@ -30,12 +30,12 @@ The possible states are: 2. CLEARING_DIR: the PG's contents are being removed synchronously 3. DELETING_DIR: the PG's directories and metadata being queued for removal 4. DELETED_DIR: the final removal transaction has been queued - 5. CANCELED: the deletion has been canceled + 5. CANCELED: the deletion has been cancelled -In 1 and 2, the deletion can be canceled. Each state transition +In 1 and 2, the deletion can be cancelled. Each state transition method (and check_canceled) returns false if deletion has been -canceled and true if the state transition was successful. Similarly, -try_stop_deletion() returns true if it succeeds in canceling the +cancelled and true if the state transition was successful. Similarly, +try_stop_deletion() returns true if it succeeds in cancelling the deletion. Additionally, try_stop_deletion() in the event that it fails to stop the deletion will not return until the final removal transaction is queued. This ensures that any operations queued after @@ -44,7 +44,7 @@ that point will be ordered after the pg deletion. OSD::_create_lock_pg must handle two cases: 1. Either there is no DeletingStateRef for the pg, or it failed to cancel - 2. We succeeded in canceling the deletion. + 2. We succeeded in cancelling the deletion. In case 1., we proceed as if there were no deletion occurring, except that we avoid writing to the PG until the deletion finishes. In case 2., we diff --git a/doc/dev/osd_internals/snaps.rst b/doc/dev/osd_internals/snaps.rst index e17378fd2a6..ed9538ba185 100644 --- a/doc/dev/osd_internals/snaps.rst +++ b/doc/dev/osd_internals/snaps.rst @@ -6,7 +6,7 @@ Overview -------- Rados supports two related snapshotting mechanisms: - 1. *pool snaps*: snapshots are implicitely applied to all objects + 1. *pool snaps*: snapshots are implicitly applied to all objects in a pool 2. *self managed snaps*: the user must provide the current *SnapContext* on each write. diff --git a/doc/dev/osd_internals/wbthrottle.rst b/doc/dev/osd_internals/wbthrottle.rst index a3ae00d82c7..9b67efbb6c8 100644 --- a/doc/dev/osd_internals/wbthrottle.rst +++ b/doc/dev/osd_internals/wbthrottle.rst @@ -3,7 +3,7 @@ Writeback Throttle ================== Previously, the filestore had a problem when handling large numbers of -small ios. We throttle dirty data implicitely via the journal, but +small ios. We throttle dirty data implicitly via the journal, but a large number of inodes can be dirtied without filling the journal resulting in a very long sync time when the sync finally does happen. The flusher was not an adequate solution to this problem since it @@ -18,7 +18,7 @@ See src/os/WBThrottle.h, src/osd/WBThrottle.cc To track the open FDs through the writeback process, there is now an fdcache to cache open fds. lfn_open now returns a cached FDRef which -implicitely closes the fd once all references have expired. +implicitly closes the fd once all references have expired. Filestore syncs have a sideeffect of flushing all outstanding objects in the wbthrottle. -- 2.39.5