doc: Fix Typos of Developer Guide

Signed-off-by: Li Bingyang <li.bingyang1@zte.com.cn>

diff --git a/doc/dev/rados-client-protocol.rst b/doc/dev/rados-client-protocol.rst
index b05e7534404b268b9dd1649c007b2e07f73286ef..da3d73dae6fc91df96c3caf31db386ac408fb474 100644 (file)
--- 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 3b2ef059dd1eb769c89db12572b675cc159c7053..ae2b014a658a9ead9a8523d5f90b22f8c8a4d8ff 100644 (file)
--- 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 e8a5059c69e39e4dcad986436c36b17cd13a499b..48fab623db78ecf4b391718e66dc3d7c6b65338f 100644 (file)
--- 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