Deuxfleurs/garage
41
56
Fork 73
Code Issues 98 Pull requests 14 Releases 30 Wiki Activity

Merge pull request 'doc: fix some typos' (#696) from Armael/garage:typos into main
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse source 
Reviewed-on: #696
This commit is contained in:
Alex 2024-01-28 14:15:47 +00:00
commit d45189e7b8
3 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/book/operations/durability-repairs.md
View file

@ -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

12
doc/book/operations/layout.md
View file

@ -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).

2
doc/book/operations/upgrading.md
View file

@ -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).