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
|
@ -49,7 +49,7 @@ verifications. Of course, scrubbing the entire data store will also take longer.
|
||||||
## Block check and resync
|
## Block check and resync
|
||||||
|
|
||||||
In some cases, nodes hold a reference to a block but do not actually have the block
|
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`.
|
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
|
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
|
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
|
In [multi-HDD setups](@/documentation/operations/multi-hdd.md), to ensure that
|
||||||
data blocks are well balanced between storage locations, you may run a
|
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
|
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
|
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
|
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
|
into slices which we call *partitions*. Each partition is stored by
|
||||||
one or several nodes in the cluster
|
one or several nodes in the cluster
|
||||||
(see [`replication_mode`](@/documentation/reference-manual/configuration.md#replication_mode)).
|
(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.
|
which exist on a logical level, and actual storage nodes.
|
||||||
|
|
||||||
## How cluster layouts work in Garage
|
## How cluster layouts work in Garage
|
||||||
|
@ -94,10 +94,10 @@ follow the following recommendations:
|
||||||
## Understanding unexpected layout calculations
|
## Understanding unexpected layout calculations
|
||||||
|
|
||||||
When adding, removing or modifying nodes in a cluster layout, sometimes
|
When adding, removing or modifying nodes in a cluster layout, sometimes
|
||||||
unexpected assigntations of partitions to node can occur. These assignations
|
unexpected assignations of partitions to node can occur. These assignations
|
||||||
are in fact normal and logical, given the objectives of the algorihtm. Indeed,
|
are in fact normal and logical, given the objectives of the algorithm. Indeed,
|
||||||
**the layout algorithm prioritizes moving less data between nodes over the fact
|
**the layout algorithm prioritizes moving less data between nodes over
|
||||||
of achieving equal distribution of load. It also tries to use all links between
|
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
|
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
|
two examples and illustrates how one can control Garage's behavior to obtain
|
||||||
the desired results.
|
the desired results.
|
||||||
|
@ -270,5 +270,5 @@ that is moved to node1).
|
||||||
This illustrates the second principle of the layout computation: **if there is
|
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
|
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
|
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).
|
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 and data structures remained the same ➡️ this is a **minor upgrade**
|
||||||
- protocols or data structures changed ➡️ this is a **major 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
|
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).
|
(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).
|
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