chore: a large number of typo corrections in markdown files

doc/book/operations/layout.md

@@ -242,7 +242,7 @@ dc3                 Tags   Partitions        Capacity   Usable capacity
   TOTAL                    256 (256 unique)  2.0 GB     1000.0 MB (50.0%)
 ```
 
-As we can see, the node that was moved to `dc3` (node4) is only used at 25% (approximatively),
+As we can see, the node that was moved to `dc3` (node4) is only used at 25% (approximately),
 whereas the node that was already in `dc3` (node3) is used at 75%.
 
 This can be explained by the following:
@@ -260,7 +260,7 @@ This can be explained by the following:
  data can be removed to be moved to node1.
 
 - Garage will move data in equal proportions from all possible sources, in this
-  case it means that it will tranfer 25% of the entire data set from node3 to
+  case it means that it will transfer 25% of the entire data set from node3 to
   node1 and another 25% from node4 to node1.
 
 This explains why node3 ends with 75% utilization (100% from before minus 25%

doc/book/operations/multi-hdd.md

@@ -40,7 +40,7 @@ First of all, Garage divides the set of all possible block hashes
 in a fixed number of slices (currently 1024), and assigns
 to each slice a primary storage location among the specified data directories.
 The number of slices having their primary location in each data directory
-is proportionnal to the capacity specified in the config file.
+is proportional to the capacity specified in the config file.
 
 When Garage receives a block to write, it will always write it in the primary
 directory of the slice that contains its hash.

doc/book/operations/upgrading.md

@@ -56,7 +56,7 @@ From a high level perspective, a major upgrade looks like this:
   10. Enable API access (reverse step 1)
   11. Monitor your cluster while load comes back, check that all your applications are happy with this new version
 
-### Major upgarades with minimal downtime
+### Major upgrades with minimal downtime
 
 There is only one operation that has to be coordinated cluster-wide: the switch of one version of the internal RPC protocol to the next.
 This means that an upgrade with very limited downtime can simply be performed from one major version to the next by restarting all nodes