CORTX-33878: fix Alex issues (Seagate#2081)

Fixed the issues reported by the Alex tool and added suitable 
replacement words for the issues reported.

Signed-off-by: Swapnil Chaudhary <swapnil.chaudhary@seagate.com>

CONTRIBUTING.md

@@ -175,5 +175,5 @@ Refer to the [Motr Coding Style Guide](../dev/doc/coding-style.md) and the [CORT
 
 You can reach out to us with your questions, feedback, and comments through our CORTX Communication Channels:
 
-- Join our CORTX-Open Source Slack Channel to interact with your fellow community members and gets your questions answered. [![Slack Channel](https://img.shields.io/badge/chat-on%20Slack-blue)](https://join.slack.com/t/cortxcommunity/shared_invite/zt-femhm3zm-yiCs5V9NBxh89a_709FFXQ?)
+- Join our CORTX-Open Source Slack Channel to interact with community members and gets your questions answered. [![Slack Channel](https://img.shields.io/badge/chat-on%20Slack-blue)](https://join.slack.com/t/cortxcommunity/shared_invite/zt-femhm3zm-yiCs5V9NBxh89a_709FFXQ?)
 - If you'd like to contact us directly, drop us a mail at cortx-questions@seagate.com.

SUPPORT.md

@@ -3,6 +3,6 @@ Looking for support for CORTX parent or a repository ?
 Consider some of these resources:
 
 -   Join our CORTX-Open Source Slack channel [![Slack](https://img.shields.io/badge/chat-on%20Slack-blue")](https://join.slack.com/t/cortxcommunity/shared_invite/zt-femhm3zm-yiCs5V9NBxh89a_709FFXQ?) to interact with community members and gets your questions answered.
--   Join [GitHub Discussions](https://github.com/Seagate/cortx-motr/discussions) to ask, answer, and discuss topics with your fellow CORTX contributors! 
+-   Join [GitHub Discussions](https://github.com/Seagate/cortx-motr/discussions) to ask, answer, and discuss topics with CORTX contributors! 
 -   If you'd like to contact us directly, drop us a mail at [cortx-questions@seagate.com](mailto:cortx-questions@seagate.com) .
 -   We like to highlight the work and contributions of our community members—if you have solved an interesting challenge, or you are interested in sharing your experience or use cases, we want to talk to you! Please email our Community Manager [rachel.novak@seagate.com](mailto:rachel.novak@seagate.com) or [schedule a meeting with us](https://outlook.office365.com/owa/calendar/CORTXCommunity@seagate.com/bookings/s/x8yMn2ODxUCOdhxvXkH4FA2) to share.

doc/HLD-of-SNS-Repair.md

@@ -89,7 +89,7 @@ Following topics deserve attention:
 * Details of interaction between repair and DTM must be specified.  
 * Redundancy other than N+1 (N+K, K > 1) must be regarded as a default configuration.   
 * Multiple failures and repair in the presence of multiple failures must be considered systematically.  
-* Repair and re-balancing must be clearly distinguished.    
+* Repair and re-balancing must be distinguished appropriately.
 * Reclaim of a distributed spare space must be addressed (this is done in a separate Distributed Spare design documentation).  
 * locking optimizations.
 
@@ -150,7 +150,7 @@ Agent iterates components over the affected container or all the containers whic
 ### 5.11. SNS repair and layout ###
 The SNS manager gets an input set configuration and output set configuration as the repair is initiated. These input/output sets can be described by some form of layout. The SNS repair will read the data/parity from the devices described with the input set and reconstruct the missing data. In the process of reconstruction object layouts affected by the data reconstruction (layouts with data located on the lost storage device or node) are transactionally updated to reflect changed data placement. Additionally, while the reconstruction is in-progress, all affected layouts are switched into a degraded mode so that the clients can continue to access and modify data.  
 
-Note that the standard mode of operation is a so-called "non-blocking availability" (NBA) where after a failure the client can immediately continue writing new data without any IO degradation. To this end, a client is handed out a new layout to which it can write. After this point, the cluster-wide object has a composite layout: some parts of the object's linear name-space are laid accordingly to the old layout, and other parts (ones where clients write after a failure)—are a new one. In this configuration, clients never write to the old layout, while its content is being reconstructed.  
+Note that the standard mode of operation is a so-called "non-blocking availability" (NBA) where after a failure the client can immediately continue writing new data without any IO degradation. To this end, a client is handed out a new layout to which it can write. After this point, the cluster-wide object has a composite layout: some parts of the object's linear name-space are mapped accordingly to the old layout, and other parts (ones where clients write after a failure)—are a new one. In this configuration, clients never write to the old layout, while its content is being reconstructed.  
 
 The situation where there is a client-originated IO against layouts being reconstructed is possible because of:    
 * Reads have to access old data even under NBA policy and

doc/HLD-of-SNS-client.md

@@ -42,7 +42,7 @@ External SNS client interfaces are standard Linux file_operations and address_sp
 ## Logical Specification  
 
 ### fop builder, NRS, and request handler
-A fop, representing IO operation is created at the VFS or VM entry point1. The fop is then passed to the dummy NRS(23), which immediately passes it down to the request handler. The request handler uses file meta-data to identify the layout and calls the layout IO engine to proceed with the IO operation.  
+A fop, representing IO operation is created at the VFS or VM entry point1. The fop is then passed to the fake NRS(23), which immediately passes it down to the request handler. The request handler uses file meta-data to identify the layout and calls the layout IO engine to proceed with the IO operation.  
 
 ### Layout Schema
 The layout formula generates a parity de-clustered file layout for a particular file, using file id (fid) as an identifier[2]. See Parity De-clustering Algorithm HLD [3] for details. At the moment, **m0t1fs** supports a single file with fid supplied as a mount option.    

doc/ISC-Service-User-Guide

@@ -96,11 +96,11 @@ Consider a simple API that on reception of string “Hello” responds with “W
                   char *in_string, struct m0_rpc_conn *conn)
  {
        int rc;
-       /* A string is mapped to a mero buffer. */
+       /* A string is mapped to a motr buffer. */
        m0_buf_init(in_args, in_string, strlen(in_string));
        /* Initialise RPC adaptive transmission data structure. */
        m0_rpc_at_init(&isc_fop->fi_args);
-       /* Add mero buffer to m0_rpc_at */
+       /* Add motr buffer to m0_rpc_at */
 
        rc = m0_rpc_at_add(&isc_fop->fi_args, in_args, conn);
 
@@ -198,7 +198,7 @@ We now discuss the callee side code. Let’s assume that the function is registe
      if (m0_buf_streq(in, “Hello”)) {
            /*
             * The string allocated here should not be freed by
-            * computation and Mero takes care of freeing it.
+            * computation and Motr takes care of freeing it.
             */
 
            out_str = m0_strdup(“World”);
@@ -224,7 +224,7 @@ Suppose we have a collection of arrays of integers, each stored as a Motr object
 ```
 /* Arguments for getting min/max. */
 struct arr_fids {
-     /* Number of arrays stored with Mero. */
+     /* Number of arrays stored with Motr. */
      uint32_t af_arr_nr;
      /* An array holding unique identifiers of arrays. */
      struct m0_fid *af_gfids
@@ -280,7 +280,7 @@ struct histo_args {
     /** Minimum value. */
     uint64_t ha_min_val;
 
-    /** Global fid of object stored with Mero. */
+    /** Global fid of object stored with Motr. */
     struct m0_fid ha_gob_fid;
 
 } M0_XCA_RECORD;
@@ -295,7 +295,7 @@ Here we discuss the API for generating a histogram of values, local to a node. T
  * Structure of a computation is advisable to be similar to
  * Motr foms. It returns M0_FSO_WAIT when it has to wait for
  * an external event (n/w or disk I/O)else it returns
- * M0_FSO_AGAIN. These two symbols are defined in Mero.
+ * M0_FSO_AGAIN. These two symbols are defined in Motr.
  */
 int histo_generate(struct m0_buf *in, struct m0_buf *out,
                    struct m0_isc_comp_private *comp_data,

doc/ISC-Service-User-Guide.md

@@ -96,11 +96,11 @@ Consider a simple API that on reception of string “Hello” responds with “W
                   char *in_string, struct m0_rpc_conn *conn)
  {
        int rc;
-       /* A string is mapped to a mero buffer. */
+       /* A string is mapped to a motr buffer. */
        m0_buf_init(in_args, in_string, strlen(in_string));
        /* Initialise RPC adaptive transmission data structure. */
        m0_rpc_at_init(&isc_fop->fi_args);
-       /* Add mero buffer to m0_rpc_at */
+       /* Add motr buffer to m0_rpc_at */
 
        rc = m0_rpc_at_add(&isc_fop->fi_args, in_args, conn);
 
@@ -199,7 +199,7 @@ We now discuss the callee side code. Let’s assume that the function is registe
      if (m0_buf_streq(in, “Hello”)) {
            /*
             * The string allocated here should not be freed by
-            * computation and Mero takes care of freeing it.
+            * computation and Motr takes care of freeing it.
             */
 
            out_str = m0_strdup(“World”);
@@ -225,7 +225,7 @@ Suppose we have a collection of arrays of integers, each stored as a Motr object
 ```C
 /* Arguments for getting min/max. */
 struct arr_fids {
-     /* Number of arrays stored with Mero. */
+     /* Number of arrays stored with Motr. */
      uint32_t af_arr_nr;
      /* An array holding unique identifiers of arrays. */
      struct m0_fid *af_gfids
@@ -281,7 +281,7 @@ struct histo_args {
     /** Minimum value. */
     uint64_t ha_min_val;
 
-    /** Global fid of object stored with Mero. */
+    /** Global fid of object stored with Motr. */
     struct m0_fid ha_gob_fid;
 
 } M0_XCA_RECORD;
@@ -295,7 +295,7 @@ Here we discuss the API for generating a histogram of values, local to a node. T
  * Structure of a computation is advisable to be similar to
  * Motr foms. It returns M0_FSO_WAIT when it has to wait for
  * an external event (n/w or disk I/O)else it returns
- * M0_FSO_AGAIN. These two symbols are defined in Mero.
+ * M0_FSO_AGAIN. These two symbols are defined in Motr.
  */
 ```C
 int histo_generate(struct m0_buf *in, struct m0_buf *out,

doc/Motr-Lnet-Transport.md

@@ -381,7 +381,7 @@ A Motr server uses the following pattern to use the LNet transport to initiate a
 
 A Motr tool uses the following pattern to use the LNet transport to initiate passive bulk tranfers to Motr server components:
 
-1.  The tool should use an end point address that is not assigned to any mero server or file system client. It should use a dynamic address to achieve this.
+1.  The tool should use an end point address that is not assigned to any motr server or file system client. It should use a dynamic address to achieve this.
 2.  To perform a bulk operation, the tool provisions a network buffer. The tool then registers this buffer and enqueues the buffer for transmission.
 3.  When a buffer operation completes, the buffer can be de-registered and the memory can be de-provisioned.
 
@@ -437,7 +437,7 @@ LNet is capable of running without Lustre, but currently is distributed only thr
 
 ### References
 *  [1] T1 Task Definitions
-*  [2] Mero Summary Requirements Table
+*  [2] Motr Summary Requirements Table
 *  [3] m0 Glossary
 *  [4] m0LNet Preliminary Design Questions
 *  [5] RPC Bulk Transfer Task Plan

doc/RPC_Layer_Core.rst

@@ -60,7 +60,7 @@ Requirements
 
 - [r.rpccore.efficient.bulk] 0-copy, if provided by the underlying network transport, is utilized;
 
-- [r.rpccore.eos] support ordered exactly once semantics (EOS) of delivery;
+- [r.rpccore.exactly-once-semantics] support ordered exactly once semantics of delivery;
 
 - [r.rpccore.formation.settings] support different setting like max_rpc_in_flight, max_page_per_rpc, etc.
 
@@ -239,7 +239,7 @@ Cached FOPs might have dependencies each on other. This could affect the order o
 
 - m0_rpcmachine is a RPC processing machine, several instances of it might be existing simultaneously.
 
-- m0_update_stream is an ADT associated with sessions and slots used for FOP sending with FIFO and EOS constrains.
+- m0_update_stream is an ADT associated with sessions and slots used for FOP sending with FIFO and CORTX constrains.
 
 
 *********************

doc/Seagate-FDMI-HLD.md

@@ -12,7 +12,7 @@
 
 # Introduction #
 ## 1.1 Document's Purpose ##
-The document is intended to specify the design of Mero FDMI interface. FDMI is a part of Mero product. FDMI provides interface for Mero plugins and allows horizontally extending the features and capabilities of the system.   
+The document is intended to specify the design of Motr FDMI interface. FDMI is a part of Motr product. FDMI provides interface for Motr plugins and allows horizontally extending the features and capabilities of the system.   
 
 ## 1.2 Intended Audience ##
 * Product Architect
@@ -23,12 +23,12 @@ The document is intended to specify the design of Mero FDMI interface. FDMI is a
 FDMI: File data manipulation interface
 
 ## 1.4 References ##
-1. “Mero Object Store Architecture: Technical” MeroTechnicalWhitepaper.pdf
-2. “mero a scalable storage platform” Mero technical (toi).pdf
+1. “Motr Object Store Architecture: Technical” MotrTechnicalWhitepaper.pdf
+2. “motr a scalable storage platform” Motr technical (toi).pdf
 3. fdmihighleveldecomposition.pdf	   
 
 # Overview #
-Mero is a storage core capable of deployment for a wide range of large scale storage regimes, from cloud and enterprise systems to exascale HPC installations. FDMI is a part of Mero core, providing interface for plugins implementation. FDMI is build around the core and allows for horizontally extending the features and capabilities of the system in a scalable and reliable manner.
+Motr is a storage core capable of deployment for a wide range of large scale storage regimes, from cloud and enterprise systems to exascale HPC installations. FDMI is a part of Motr core, providing interface for plugins implementation. FDMI is build around the core and allows for horizontally extending the features and capabilities of the system in a scalable and reliable manner.
 
 ## 1.5 Product Purpose ##
 TBD
@@ -52,25 +52,25 @@ In this section only architectural information like the following is displayed b
 
 
 
-## 1.7 FDMI position in overall Mero Core design ##
+## 1.7 FDMI position in overall Motr Core design ##
 
-FDMI is an interface allowing Mero Core scale horizontally. The scaling includes two aspects:
+FDMI is an interface allowing Motr Core scale horizontally. The scaling includes two aspects:
 
 * Core expansion in aspect of adding core data processing abilities, including data volumes as well as transformation into alternative representation. The expansion is provided by introducing FDMI plug-ins.
 
   * Initial design implies that FOL records are the only data plug-ins are able to process so far.
 
 * Core expansion in aspect of adding new types of data the core is able to feed plug-ins. This sort of expansion is provided by introducing FDMI sources.
 
-  * Initial design implies that FOL record is the only source data type Mero Core provides so far.
+  * Initial design implies that FOL record is the only source data type Motr Core provides so far.
 
-FDMI plug-in is an application linked with Mero Core to make use of corresponding FDMI interfaces and run separate from Mero instance/services. The purpose of introducing plug-in is getting notifications from Mero Core about particular changes in stored data and further post-processing of the data intended for producing some additional classes of data the Core currently is not able to provide.
+FDMI plug-in is an application linked with Motr Core to make use of corresponding FDMI interfaces and run separate from Motr instance/services. The purpose of introducing plug-in is getting notifications from Motr Core about particular changes in stored data and further post-processing of the data intended for producing some additional classes of data the Core currently is not able to provide.
 
 
-Instead, FDMI source appears to be a part of Mero instance being linked with appropriate FDMI interfaces and allowing connection to additional data providers.
+Instead, FDMI source appears to be a part of Motr instance being linked with appropriate FDMI interfaces and allowing connection to additional data providers.
 
 
-Considering the amount of data Mero Core operates with it obvious that plug-in typically requires a sufficiently reduced bulk of data to be routed to it for post-processing. The reduction is provided by introduction of mechanism of subscription to particular data types and conditions met at runtime. The subscription mechanism is based on set of filters the plug-in registers in Mero Filter Database during its initialization.
+Considering the amount of data Motr Core operates with it obvious that plug-in typically requires a sufficiently reduced bulk of data to be routed to it for post-processing. The reduction is provided by introduction of mechanism of subscription to particular data types and conditions met at runtime. The subscription mechanism is based on set of filters the plug-in registers in Motr Filter Database during its initialization.
 
 
 Source in its turn refreshes its own subset of filters against the database. The subset is selected from overall filter set based on the knowledge about data types the source is able to feed FDMI with as well as operation with the data the source supports.   
@@ -80,7 +80,7 @@ FDMI consists of APIs implementing particular roles in accordance with FDMI use
 
 * Plug-in dock, responsible for:
   * Plug-in registration in FDMI instance
-  * Filter registration in Mero Filter Database
+  * Filter registration in Motr Filter Database
   * Listening to notifications coming over RPC
   * Payload processing
   * Self-diagnostic (TBD)  
@@ -89,7 +89,7 @@ FDMI consists of APIs implementing particular roles in accordance with FDMI use
   * Source registration
   * Retrieving/refreshing filter set for the source
   * Input data filtration
-  * Deciding on and posting notifications to filter subscribers over Mero RPC
+  * Deciding on and posting notifications to filter subscribers over Motr RPC
   * Deferred input data release
   * Self-diagnostic (TBD)
 
@@ -176,6 +176,6 @@ Input data may require to remain locked in the Source until the moment when plug
 ![image](./images/Image8_FDMIserviceFoundDead.PNG)  
 
 
-When interaction between Mero services results in a timeout exceeding pre-configured value, the not responding service needs to be announced dead across the whole system. First of all **confd** service is notified about the service not responding. After being marked dead in **confd** database, the service has to be reported to **filterd** as well. The main purpose is to deregister FDMI sources hosted by the service, if any, to stop propagating **filterd** database changes to those.  
+When interaction between Motr services results in a timeout exceeding pre-configured value, the not responding service needs to be announced dead across the whole system. First of all **confd** service is notified about the service not responding. After being marked dead in **confd** database, the service has to be reported to **filterd** as well. The main purpose is to deregister FDMI sources hosted by the service, if any, to stop propagating **filterd** database changes to those.  
 
 As well, the moment of the last instance of the source type coming out, the corresponding plug-ins might be notified.

doc/faq.rst

@@ -43,6 +43,6 @@ Mero -> Motr rename
         make[1]: *** [all-recursive] Error 1
         make: *** [all] Error 2
 
-   A: Remove ``/etc/ld.so.conf.d/mero.conf``, then rebuild Motr after ``git
+   A: Remove ``/etc/ld.so.conf.d/motr.conf``, then rebuild Motr after ``git
    clean -dfx`` (WARNING: removes all files that are not staged and are not in
    the repo).