diff options
Diffstat (limited to 'doc/book')
-rw-r--r-- | doc/book/quick-start/_index.md | 2 | ||||
-rw-r--r-- | doc/book/reference-manual/features.md | 2 | ||||
-rw-r--r-- | doc/book/reference-manual/monitoring.md | 2 | ||||
-rw-r--r-- | doc/book/working-documents/design-draft.md | 4 | ||||
-rw-r--r-- | doc/book/working-documents/migration-04.md | 2 | ||||
-rw-r--r-- | doc/book/working-documents/testing-strategy.md | 2 |
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 |