docs/Administrator-Guide/arbiter-volumes-and-quorum.md: formatting 'r…

…eplica 2 volume' etc. to be more readable

docs/Administrator-Guide/arbiter-volumes-and-quorum.md

@@ -2,7 +2,7 @@
 
 The arbiter volume is a special subset of replica volumes that is aimed at
 preventing split-brains and providing the same consistency guarantees as a normal
-replica 3 volume without consuming 3x space. 
+`replica 3` volume without consuming 3x space.
 
 <!-- TOC depthFrom:1 depthTo:6 withLinks:1 updateOnSave:1 orderedList:0 -->
 
@@ -129,7 +129,7 @@ greater than 50%, so that two nodes separated from each other do not believe
 they have quorum simultaneously. For a two-node plain replica volume, this would
 mean both nodes need to be up and running. So there is no notion of HA/failover.
 
-There are users who create a replica 2 volume from 2 nodes and peer-probe
+There are users who create a `replica 2` volume from 2 nodes and peer-probe
 a 'dummy' node without bricks and enable server quorum with a ratio of 51%.
 This does not prevent files from getting into split-brain. For example, if B1
 and B2 are the bricks/nodes of the replica and B3 is the dummy node, we can
@@ -184,16 +184,16 @@ This means the ```cluster.quorum-reads``` volume option is also not supported.
 ## Replica 2 and Replica 3 volumes
 
 From the above descriptions, it is clear that client-quorum cannot really be applied
-to a replica 2 volume:(without costing HA).
+to a `replica 2` volume (without costing HA).
 If the quorum-type is set to auto, then by the description
 given earlier, the first brick must always be up, irrespective of the status of the
 second brick. IOW, if only the second brick is up, the subvol returns ENOTCONN, i.e. no HA.
 If quorum-type is set to fixed, then the quorum-count *has* to be two
 to prevent split-brains (otherwise a write can succeed in brick1, another in brick2 =>split-brain).
-So for all practical purposes, if you want high availability in a replica 2 volume,
+So for all practical purposes, if you want high availability in a `replica 2` volume,
 it is recommended not to enable client-quorum.
 
-In a replica 3 volume, client-quorum is enabled by default and set to 'auto'.
+In a `replica 3` volume, client-quorum is enabled by default and set to 'auto'.
 This means 2 bricks need to be up for the write to succeed. Here is how this
 configuration prevents files from ending up in split-brain: