Addressed review comments and fixed alex issues from the new report

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/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.cortx] support ordered exactly once semantics (CORTX) 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.
 

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.