Merge pull request 'Fix all typos' (#928) from majst01/garage:fix-typos into mainHEADmain

Reviewed-on: https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/928
Reviewed-by: maximilien <me@mricher.fr>

6 files changed, 7 insertions, 7 deletions

diff --git a/doc/book/quick-start/_index.md b/doc/book/quick-start/_index.md
index b5eb646f..b74500d5 100644
--- a/doc/book/quick-start/_index.md
+++ b/doc/book/quick-start/_index.md
@@ -349,7 +349,7 @@ Check [our s3 compatibility list](@/documentation/reference-manual/s3-compatibil
 
 ### Other tools for interacting with Garage
 
-The following tools can also be used to send and recieve files from/to Garage:
+The following tools can also be used to send and receive files from/to Garage:
 
 - [minio-client](@/documentation/connect/cli.md#minio-client) 
 - [s3cmd](@/documentation/connect/cli.md#s3cmd) 
diff --git a/doc/book/reference-manual/features.md b/doc/book/reference-manual/features.md
index 34f692cc..481aef01 100644
--- a/doc/book/reference-manual/features.md
+++ b/doc/book/reference-manual/features.md
@@ -61,7 +61,7 @@ directed to a Garage cluster can be handled independently of one another instead
 of going through a central bottleneck (the leader node).
 As a consequence, requests can be handled much faster, even in cases where latency
 between cluster nodes is important (see our [benchmarks](@/documentation/design/benchmarks/index.md) for data on this).
-This is particularly usefull when nodes are far from one another and talk to one other through standard Internet connections.
+This is particularly useful when nodes are far from one another and talk to one other through standard Internet connections.
 
 ### Web server for static websites
 
diff --git a/doc/book/reference-manual/monitoring.md b/doc/book/reference-manual/monitoring.md
index 53608d95..4696791e 100644
--- a/doc/book/reference-manual/monitoring.md
+++ b/doc/book/reference-manual/monitoring.md
@@ -392,7 +392,7 @@ table_merkle_updater_todo_queue_length{table_name="block_ref"} 0
 
 #### `table_sync_items_received`, `table_sync_items_sent` (counters)
 
-Number of data items sent to/recieved from other nodes during resync procedures
+Number of data items sent to/received from other nodes during resync procedures
 
 ```
 table_sync_items_received{from="<remote node>",table_name="bucket_v2"} 3
diff --git a/doc/book/working-documents/design-draft.md b/doc/book/working-documents/design-draft.md
index 6560dbed..8d3a31f0 100644
--- a/doc/book/working-documents/design-draft.md
+++ b/doc/book/working-documents/design-draft.md
@@ -42,7 +42,7 @@ The general principle are similar, but details have not been updated.**
 A version is defined by the existence of at least one entry in the blocks table for a certain version UUID.
 We must keep the following invariant: if a version exists in the blocks table, it has to be referenced in the objects table.
 We explicitly manage concurrent versions of an object: the version timestamp and version UUID columns are index columns, thus we may have several concurrent versions of an object.
-Important: before deleting an older version from the objects table, we must make sure that we did a successfull delete of the blocks of that version from the blocks table.
+Important: before deleting an older version from the objects table, we must make sure that we did a successful delete of the blocks of that version from the blocks table.
 
 Thus, the workflow for reading an object is as follows:
 
@@ -95,7 +95,7 @@ Known issue: if someone is reading from a version that we want to delete and the
 Usefull metadata:
 
 - list of versions that reference this block in the Casandra table, so that we can do GC by checking in Cassandra that the lines still exist
-- list of other nodes that we know have acknowledged a write of this block, usefull in the rebalancing algorithm
+- list of other nodes that we know have acknowledged a write of this block, useful in the rebalancing algorithm
 
 Write strategy: have a single thread that does all write IO so that it is serialized (or have several threads that manage independent parts of the hash space). When writing a blob, write it to a temporary file, close, then rename so that a concurrent read gets a consistent result (either not found or found with whole content).
 
diff --git a/doc/book/working-documents/migration-04.md b/doc/book/working-documents/migration-04.md
index d9d3ede1..52c56737 100644
--- a/doc/book/working-documents/migration-04.md
+++ b/doc/book/working-documents/migration-04.md
@@ -68,7 +68,7 @@ The migration steps are as follows:
 5. Turn off Garage 0.3
 
 6. Backup metadata folders if you can (i.e. if you have space to do it
-   somewhere). Backuping data folders could also be usefull but that's much
+   somewhere). Backuping data folders could also be useful but that's much
    harder to do. If your filesystem supports snapshots, this could be a good
    time to use them.
 
diff --git a/doc/book/working-documents/testing-strategy.md b/doc/book/working-documents/testing-strategy.md
index 7d6be8ef..fff706d7 100644
--- a/doc/book/working-documents/testing-strategy.md
+++ b/doc/book/working-documents/testing-strategy.md
@@ -37,7 +37,7 @@ There are two reasons for this:
 
 Reminder: rules of simplicity, concerning changes to Garage's source code.
 Always question what we are doing.
-Never do anything just because it looks nice or because we "think" it might be usefull at some later point but without knowing precisely why/when.
+Never do anything just because it looks nice or because we "think" it might be useful at some later point but without knowing precisely why/when.
 Only do things that make perfect sense in the context of what we currently know.
 
 ## References