doc: fix some typos

doc/book/operations/durability-repairs.md

@@ -49,7 +49,7 @@ verifications. Of course, scrubbing the entire data store will also take longer.
 ## Block check and resync
 
 In some cases, nodes hold a reference to a block but do not actually have the block
-stored on disk. Conversely, they may also have on disk blocks that are not referenced
+stored on disk. Conversely, they may also have on-disk blocks that are not referenced
 any more. To fix both cases, a block repair may be run with `garage repair blocks`.
 This will scan the entire block reference counter table to check that the blocks
 exist on disk, and will scan the entire disk store to check that stored blocks
@@ -95,7 +95,7 @@ using the `garage block purge` command.
 
 In [multi-HDD setups](@/documentation/operations/multi-hdd.md), to ensure that
 data blocks are well balanced between storage locations, you may run a
-rebalance operation using `garage repair rebalance`. This is usefull when
+rebalance operation using `garage repair rebalance`. This is useful when
 adding storage locations or when capacities of the storage locations have been
 changed.  Once this is finished, Garage will know for each block of a single
 possible location where it can be, which can increase access speed.  This

doc/book/operations/layout.md

@@ -13,7 +13,7 @@ In Garage, all of the data that can be stored in a given cluster is divided
 into slices which we call *partitions*. Each partition is stored by
 one or several nodes in the cluster
 (see [`replication_mode`](@/documentation/reference-manual/configuration.md#replication_mode)).
-The layout determines the correspondence between these partition,
+The layout determines the correspondence between these partitions,
 which exist on a logical level, and actual storage nodes.
 
 ## How cluster layouts work in Garage
@@ -94,10 +94,10 @@ follow the following recommendations:
 ## Understanding unexpected layout calculations
 
 When adding, removing or modifying nodes in a cluster layout, sometimes
-unexpected assigntations of partitions to node can occur. These assignations
-are in fact normal and logical, given the objectives of the algorihtm.  Indeed,
-**the layout algorithm prioritizes moving less data between nodes over the fact
-of achieving equal distribution of load. It also tries to use all links between
+unexpected assignations of partitions to node can occur. These assignations
+are in fact normal and logical, given the objectives of the algorithm.  Indeed,
+**the layout algorithm prioritizes moving less data between nodes over
+achieving equal distribution of load. It also tries to use all links between
 pairs of nodes in equal proportions when moving data.**  This section presents
 two examples and illustrates how one can control Garage's behavior to obtain
 the desired results.
@@ -270,5 +270,5 @@ that is moved to node1).
 This illustrates the second principle of the layout computation: **if there is
 a choice in moving data out of some nodes, then all links between pairs of
 nodes are used in equal proportions** (this is approximately true, there is
-randomness in the algorihtm to achieve this so there might be some small
+randomness in the algorithm to achieve this so there might be some small
 fluctuations, as we see above).

doc/book/operations/upgrading.md

@@ -9,7 +9,7 @@ On a new version release, there is 2 possibilities:
   - protocols and data structures remained the same ➡️ this is a **minor upgrade**
   - protocols or data structures changed  ➡️  this is a **major upgrade**
 
-You can quickly now what type of update you will have to operate by looking at the version identifier:
+You can quickly know what type of update you will have to operate by looking at the version identifier:
 when we require our users to do a major upgrade, we will always bump the first nonzero component of the version identifier
 (e.g. from v0.7.2 to v0.8.0).
 Conversely, for versions that only require a minor upgrade, the first nonzero component will always stay the same (e.g. from v0.8.0 to v0.8.1).