forked from Deuxfleurs/garage
Merge pull request 'doc: fix some typos' (#696) from Armael/garage:typos into main
Reviewed-on: Deuxfleurs/garage#696
This commit is contained in:
commit
d45189e7b8
3 changed files with 9 additions and 9 deletions
doc/book/operations
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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).
|
||||
|
|
Loading…
Reference in a new issue