chore: a large number of typo corrections in markdown files

doc/book/working-documents/compatibility-target.md

@@ -3,7 +3,7 @@ title = "S3 compatibility target"
 weight = 5
 +++
 
-If there is a specific S3 functionnality you have a need for, feel free to open
+If there is a specific S3 functionality you have a need for, feel free to open
 a PR to put the corresponding endpoints higher in the list.  Please explain
 your motivations for doing so in the PR message.
 

doc/book/working-documents/design-draft.md

@@ -68,7 +68,7 @@ Workflow for DELETE:
 1. Check write permission (LDAP)
 2. Get current version (or versions) in object table
 3. Do the deletion of those versions NOT IN A BACKGROUND JOB THIS TIME
-4. Return succes to the user if we were able to delete blocks from the blocks table and entries from the object table
+4. Return success to the user if we were able to delete blocks from the blocks table and entries from the object table
 
 To delete a version:
 
@@ -92,7 +92,7 @@ Known issue: if someone is reading from a version that we want to delete and the
 - file path = /meta/(first 3 hex digits of hash)/(rest of hash)
 - map block hash -> set of version UUIDs where it is referenced
 
-Usefull metadata:
+Useful 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, useful in the rebalancing algorithm

doc/book/working-documents/load-balancing.md

@@ -49,12 +49,12 @@ The ring construction that selects `n_token` random positions for each nodes giv
 is not well-balanced: the space between the tokens varies a lot, and some partitions are thus bigger than others.
 This problem was demonstrated in the original Dynamo DB paper.
 
-To solve this, we want to apply a better second method for partitionning our dataset:
+To solve this, we want to apply a better second method for partitioning our dataset:
 
 1. fix an initially large number of partitions (say 1024) with evenly-spaced delimiters, 
 
 2. attribute each partition randomly to a node, with a probability
-   proportionnal to its capacity (which `n_tokens` represented in the first
+   proportional to its capacity (which `n_tokens` represented in the first
    method)
 
 For now we continue using the multi-DC ring walking described above.
@@ -66,7 +66,7 @@ I have studied two ways to do the attribution of partitions to nodes, in a way t
 
 MagLev provided significantly better balancing, as it guarantees that the exact
 same number of partitions is attributed to all nodes that have the same
-capacity (and that this number is proportionnal to the node's capacity, except
+capacity (and that this number is proportional to the node's capacity, except
 for large values), however in both cases:
 
 - the distribution is still bad, because we use the naive multi-DC ring walking

doc/book/working-documents/migration-07.md

@@ -19,7 +19,7 @@ The migration steps are as follows:
 2. Disable API and web access. Garage does not support disabling
    these endpoints but you can change the port number or stop your reverse
    proxy for instance.
-3. Check once again that your cluster is healty. Run again `garage repair --all-nodes --yes tables` which is quick.
+3. Check once again that your cluster is healthy. Run again `garage repair --all-nodes --yes tables` which is quick.
    Also check your queues are empty, run `garage stats` to query them.
 4. Turn off Garage v0.6
 5. Backup the metadata folder of all your nodes: `cd /var/lib/garage ; tar -acf meta-v0.6.tar.zst meta/`

doc/book/working-documents/testing-strategy.md

@@ -28,11 +28,11 @@ We should try to test in least invasive ways, i.e. minimize the impact of the te
 - Not making `garage` a shared library (launch using `execve`, it's perfectly fine)
 
 Instead, we should focus on building a clean outer interface for the `garage` binary,
-for example loading configuration using environnement variables instead of the configuration file if that's helpfull for writing the tests.
+for example loading configuration using environment variables instead of the configuration file if that's helpful for writing the tests.
 
 There are two reasons for this:
 
-- Keep the soure code clean and focused
+- Keep the source code clean and focused
 - Test something that is as close as possible as the true garage that will actually be running
 
 Reminder: rules of simplicity, concerning changes to Garage's source code.
@@ -71,5 +71,3 @@ Interesting blog posts on the blog of the Sled database:
 Misc:
   - [mutagen](https://github.com/llogiq/mutagen) - mutation testing is a way to assert our test quality by mutating the code and see if the mutation makes the tests fail
   - [fuzzing](https://rust-fuzz.github.io/book/) - cargo supports fuzzing, it could be a way to test our software reliability in presence of garbage data.
-  
-