From: Pulkit Mittal <2pulkit2@gmail.com> Date: Thu, 22 Jul 2021 08:18:07 +0000 (+0530) Subject: doc: fix typo and grammar X-Git-Tag: v17.1.0~1318^2 X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=refs%2Fpull%2F42365%2Fhead;p=ceph.git doc: fix typo and grammar Signed-off-by: Pulkit Mittal <2pulkit2@gmail.com> --- diff --git a/doc/dev/osd_internals/erasure_coding/ecbackend.rst b/doc/dev/osd_internals/erasure_coding/ecbackend.rst index 624ec217ea13..877a08a384aa 100644 --- a/doc/dev/osd_internals/erasure_coding/ecbackend.rst +++ b/doc/dev/osd_internals/erasure_coding/ecbackend.rst @@ -2,18 +2,18 @@ ECBackend Implementation Strategy ================================= -Misc initial design notes -========================= +Miscellaneous initial design notes +================================== -The initial (and still true for ec pools without the hacky ec -overwrites debug flag enabled) design for ec pools restricted -EC pools to operations which can be easily rolled back: +The initial (and still true for EC pools without the hacky EC +overwrites debug flag enabled) design for EC pools restricted +EC pools to operations that can be easily rolled back: - CEPH_OSD_OP_APPEND: We can roll back an append locally by including the previous object size as part of the PG log event. - CEPH_OSD_OP_DELETE: The possibility of rolling back a delete requires that we retain the deleted object until all replicas have - persisted the deletion event. ErasureCoded backend will therefore + persisted in the deletion event. Erasure Coded backend will therefore need to store objects with the version at which they were created included in the key provided to the filestore. Old versions of an object can be pruned when all replicas have committed up to the log @@ -30,7 +30,7 @@ PGTemp and Crush Primaries are able to request a temp acting set mapping in order to allow an up-to-date OSD to serve requests while a new primary is -backfilled (and for other reasons). An erasure coded pg needs to be +backfilled (and for other reasons). An erasure coded PG needs to be able to designate a primary for these reasons without putting it in the first position of the acting set. It also needs to be able to leave holes in the requested acting set. @@ -54,38 +54,38 @@ acting set have different pieces of the erasure coding scheme and are not interchangeable. Worse, crush might cause chunk 2 to be written to an OSD which happens already to contain an (old) copy of chunk 4. This means that the OSD and PG messages need to work in terms of a -type like pair in order to distinguish different pg +type like pair in order to distinguish different PG chunks on a single OSD. -Because the mapping of object name to object in the filestore must +Because the mapping of an object name to object in the filestore must be 1-to-1, we must ensure that the objects in chunk 2 and the objects -in chunk 4 have different names. To that end, the objectstore must +in chunk 4 have different names. To that end, the object store must include the chunk id in the object key. Core changes: -- The objectstore `ghobject_t needs to also include a chunk id +- The object store `ghobject_t needs to also include a chunk id `_ making it more like tuple. - coll_t needs to include a shard_t. -- The OSD pg_map and similar pg mappings need to work in terms of a +- The OSD pg_map and similar PG mappings need to work in terms of a spg_t (essentially pair). Similarly, pg->pg messages need to include a shard_t - For client->PG messages, the OSD will need a way to know which PG chunk should get the message since the OSD may contain both a - primary and non-primary chunk for the same pg + primary and non-primary chunk for the same PG Object Classes -------------- -Reads from object classes will return ENOTSUP on ec pools by invoking +Reads from object classes will return ENOTSUP on EC pools by invoking a special SYNC read. Scrub ----- -The main catch, however, for ec pools is that sending a crc32 of the +The main catch, however, for EC pools is that sending a crc32 of the stored chunk on a replica isn't particularly helpful since the chunks on different replicas presumably store different data. Because we don't support overwrites except via DELETE, however, we have the @@ -116,7 +116,7 @@ multiple stripes of a single object. There must be code that tessellates the application level write into a set of per-stripe write operations -- some whole-stripes and up to two partial stripes. Without loss of generality, for the remainder of this -document we will focus exclusively on writing a single stripe (whole +document, we will focus exclusively on writing a single stripe (whole or partial). We will use the symbol "W" to represent the number of blocks within a stripe that are being written, i.e., W <= K. @@ -125,13 +125,13 @@ choice of which of the three data flows to choose is based on the size of the write operation and the arithmetic properties of the selected parity-generation algorithm. -(1) whole stripe is written/overwritten -(2) a read-modify-write operation is performed. +(1) Whole stripe is written/overwritten +(2) A read-modify-write operation is performed. WHOLE STRIPE WRITE ------------------ -This is the simple case, and is already performed in the existing code +This is a simple case, and is already performed in the existing code (for appends, that is). The primary receives all of the data for the stripe in the RADOS request, computes the appropriate parity blocks and send the data and parity blocks to their destination shards which @@ -149,23 +149,23 @@ written. The RADOS operation is acknowledged. OSD Object Write and Consistency -------------------------------- -Regardless of the algorithm chosen above, writing of the data is a two +Regardless of the algorithm chosen above, writing of the data is a two- phase process: commit and rollforward. The primary sends the log entries with the operation described (see osd_types.h:TransactionInfo::(LocalRollForward|LocalRollBack). In all cases, the "commit" is performed in place, possibly leaving some information required for a rollback in a write-aside object. The rollforward phase occurs once all acting set replicas have committed -the commit (sorry, overloaded term) and removes the rollback information. +the commit, it then removes the rollback information. -In the case of overwrites of exsting stripes, the rollback information +In the case of overwrites of existing stripes, the rollback information has the form of a sparse object containing the old values of the overwritten extents populated using clone_range. This is essentially a place-holder implementation, in real life, bluestore will have an efficient primitive for this. The rollforward part can be delayed since we report the operation as -committed once all replicas have committed. Currently, whenever we +committed once all replicas have been committed. Currently, whenever we send a write, we also indicate that all previously committed operations should be rolled forward (see ECBackend::try_reads_to_commit). If there aren't any in the pipeline @@ -185,7 +185,7 @@ from the pipeline. See ExtentCache.h for a detailed explanation of how the cache states correspond to the higher level invariants about the conditions -under which cuncurrent operations can refer to the same object. +under which concurrent operations can refer to the same object. Pipeline -------- @@ -193,7 +193,7 @@ Pipeline Reading src/osd/ExtentCache.h should have given a good idea of how operations might overlap. There are several states involved in processing a write operation and an important invariant which -isn't enforced by PrimaryLogPG at a higher level which need to be +isn't enforced by PrimaryLogPG at a higher level which needs to be managed by ECBackend. The important invariant is that we can't have uncacheable and rmw operations running at the same time on the same object. For simplicity, we simply enforce that any @@ -204,4 +204,3 @@ There are improvements to be made here in the future. For more details, see ECBackend::waiting_* and ECBackend::try__to_. -