diff options
| -rw-r--r-- | doc/book/operations/durability-repairs.md | 4 | ||||
| -rw-r--r-- | doc/book/operations/layout.md | 12 | ||||
| -rw-r--r-- | doc/book/operations/upgrading.md | 2 |
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). |