aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/book/operations/durability-repairs.md4
-rw-r--r--doc/book/operations/layout.md12
-rw-r--r--doc/book/operations/upgrading.md2
3 files changed, 9 insertions, 9 deletions
diff --git a/doc/book/operations/durability-repairs.md b/doc/book/operations/durability-repairs.md
index b0d2c78a..578899a8 100644
--- a/doc/book/operations/durability-repairs.md
+++ b/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
diff --git a/doc/book/operations/layout.md b/doc/book/operations/layout.md
index ee05aba1..cf1372b0 100644
--- a/doc/book/operations/layout.md
+++ b/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).
diff --git a/doc/book/operations/upgrading.md b/doc/book/operations/upgrading.md
index 9a738282..6b6ea26d 100644
--- a/doc/book/operations/upgrading.md
+++ b/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).