Fix all typos

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) 

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
 

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

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

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.
 

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

doc/drafts/k2v-spec.md

@@ -562,7 +562,7 @@ token>", v: ["<value1>", ...] }`, with the following fields:
 - in case of concurrent update and deletion, a `null` is added to the list of concurrent values
 
 - if the `tombstones` query parameter is set to `true`, tombstones are returned
-  for items that have been deleted (this can be usefull for inserting after an
+  for items that have been deleted (this can be useful for inserting after an
   item that has been deleted, so that the insert is not considered
   concurrent with the delete). Tombstones are returned as tuples in the
   same format with only `null` values