From 64613065ac55de2dfd6db0bb565841f81a3402eb Mon Sep 17 00:00:00 2001 From: =?utf8?q?=E6=9D=8E=E4=B8=99=E6=B4=8B=2010208981?= Date: Mon, 17 Sep 2018 09:59:24 +0800 Subject: [PATCH] doc: Fix Typos of Developer Guide Signed-off-by: Li Bingyang --- doc/dev/rados-client-protocol.rst | 8 ++++---- doc/dev/seastore.rst | 2 +- doc/dev/session_authentication.rst | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/dev/rados-client-protocol.rst b/doc/dev/rados-client-protocol.rst index b05e7534404b2..da3d73dae6fc9 100644 --- a/doc/dev/rados-client-protocol.rst +++ b/doc/dev/rados-client-protocol.rst @@ -8,7 +8,7 @@ Basics Requests are MOSDOp messages. Replies are MOSDOpReply messages. -An object request is targetted at an hobject_t, which includes a pool, +An object request is targeted at an hobject_t, which includes a pool, hash value, object name, placement key (usually empty), and snapid. The hash value is a 32-bit hash value, normally generated by hashing @@ -24,7 +24,7 @@ the request are PG ops. Either way, the request ultimately targets a PG, either by using the explicit pgid or by folding the hash value onto the current number of pgs in the pool. The client sends the request to the primary for the -assocated PG. +associated PG. Each request is assigned a unique tid. @@ -32,7 +32,7 @@ Resends ------- If there is a connection drop, the client will resend any outstanding -requets. +requests. Any time there is a PG mapping change such that the primary changes, the client is responsible for resending the request. Note that @@ -57,7 +57,7 @@ first time it is 0, the next 1, etc. Backoff ------- -Ordinarily the OSD will simply queue any requests it can't immeidately +Ordinarily the OSD will simply queue any requests it can't immediately process in memory until such time as it can. This can become problematic because the OSD limits the total amount of RAM consumed by incoming messages: if either of the thresholds for the number of diff --git a/doc/dev/seastore.rst b/doc/dev/seastore.rst index 3b2ef059dd1eb..ae2b014a658a9 100644 --- a/doc/dev/seastore.rst +++ b/doc/dev/seastore.rst @@ -47,7 +47,7 @@ likely to be on the order of 100's of MB to tens of GB. SeaStore's logical segments would ideally be perfectly aligned with the hardware segments. In practice, it may be challenging to determine geometry and to sufficiently hint to the device that LBAs -being written shoudl be aligned to the underlying hardware. In the +being written should be aligned to the underlying hardware. In the worst case, we can structure our logical segments to correspond to e.g. 5x the physical segment size so that we have about ~20% of our data misaligned. diff --git a/doc/dev/session_authentication.rst b/doc/dev/session_authentication.rst index e8a5059c69e39..48fab623db78e 100644 --- a/doc/dev/session_authentication.rst +++ b/doc/dev/session_authentication.rst @@ -122,7 +122,7 @@ on the raw data in the message. The encryption is performed with the same ``enc routine used on the sending end, using the key stored in the local ``session\_security`` data structure. -If everything checks out, the CEPHX routine returns 0, indicating succcess. If there is a +If everything checks out, the CEPHX routine returns 0, indicating success. If there is a problem, the routine returns ``SESSION\_SIGNATURE\_FAILURE``. Adding New Session Authentication Methods -- 2.39.5