From 43ed68c558cd74db9cddf2ff0f1e17c4a8330795 Mon Sep 17 00:00:00 2001 From: Gwen Lg Date: Tue, 27 Jan 2026 17:08:43 +0100 Subject: [PATCH] chore: a large number of typo corrections in markdown files --- doc/book/build/_index.md | 2 +- doc/book/build/others.md | 6 ++--- doc/book/connect/_index.md | 2 +- doc/book/connect/apps/index.md | 10 ++++---- doc/book/connect/cli.md | 4 ++-- doc/book/connect/repositories.md | 4 +--- doc/book/cookbook/ansible.md | 2 +- doc/book/cookbook/encryption.md | 8 +++---- doc/book/cookbook/exposing-websites.md | 2 +- doc/book/cookbook/from-source.md | 4 ++-- doc/book/cookbook/kubernetes.md | 2 +- doc/book/cookbook/reverse-proxy.md | 2 +- doc/book/cookbook/systemd.md | 2 +- doc/book/design/_index.md | 4 +--- doc/book/design/benchmarks/index.md | 10 ++++---- doc/book/design/internals.md | 3 +-- doc/book/design/related-work.md | 4 ++-- doc/book/development/release-process.md | 8 +++---- doc/book/operations/layout.md | 4 ++-- doc/book/operations/multi-hdd.md | 2 +- doc/book/operations/upgrading.md | 2 +- doc/book/reference-manual/configuration.md | 24 +++++++++---------- doc/book/reference-manual/features.md | 8 +++---- doc/book/reference-manual/k2v.md | 3 +-- doc/book/reference-manual/s3-compatibility.md | 11 ++++----- .../working-documents/compatibility-target.md | 2 +- doc/book/working-documents/design-draft.md | 4 ++-- doc/book/working-documents/load-balancing.md | 6 ++--- doc/book/working-documents/migration-07.md | 2 +- .../working-documents/testing-strategy.md | 6 ++--- doc/drafts/admin-api.md | 10 ++++---- doc/drafts/k2v-spec.md | 12 +++++----- script/helm/garage/README.md | 4 ++-- script/jepsen.garage/README.md | 6 ++--- 34 files changed, 87 insertions(+), 98 deletions(-) diff --git a/doc/book/build/_index.md b/doc/book/build/_index.md index 021045aa..6a01ef57 100644 --- a/doc/book/build/_index.md +++ b/doc/book/build/_index.md @@ -51,4 +51,4 @@ We are currently building this SDK for [Python](@/documentation/build/python.md# More information: - [In the reference manual](@/documentation/reference-manual/admin-api.md) - - [Full specifiction](https://garagehq.deuxfleurs.fr/api/garage-admin-v0.html) + - [Full specification](https://garagehq.deuxfleurs.fr/api/garage-admin-v0.html) diff --git a/doc/book/build/others.md b/doc/book/build/others.md index 341e82d5..df055e79 100644 --- a/doc/book/build/others.md +++ b/doc/book/build/others.md @@ -5,13 +5,13 @@ weight = 99 ## S3 -If you are developping a new application, you may want to use Garage to store your user's media. +If you are developing a new application, you may want to use Garage to store your user's media. The S3 API that Garage uses is a standard REST API, so as long as you can make HTTP requests, you can query it. You can check the [S3 REST API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/API_Operations_Amazon_Simple_Storage_Service.html) from Amazon to learn more. -Developping your own wrapper around the REST API is time consuming and complicated. -Instead, there are some libraries already avalaible. +Developing your own wrapper around the REST API is time consuming and complicated. +Instead, there are some libraries already available. Some of them are maintained by Amazon, some by Minio, others by the community. diff --git a/doc/book/connect/_index.md b/doc/book/connect/_index.md index 7d8e686c..497f97a9 100644 --- a/doc/book/connect/_index.md +++ b/doc/book/connect/_index.md @@ -23,7 +23,7 @@ To configure S3-compatible software to interact with Garage, you will need the following parameters: - An **API endpoint**: this corresponds to the HTTP or HTTPS address - used to contact the Garage server. When runing Garage locally this will usually + used to contact the Garage server. When running Garage locally this will usually be `http://127.0.0.1:3900`. In a real-world setting, you would usually have a reverse-proxy that adds TLS support and makes your Garage server available under a public hostname such as `https://garage.example.com`. diff --git a/doc/book/connect/apps/index.md b/doc/book/connect/apps/index.md index 25f7fcf7..627f1842 100644 --- a/doc/book/connect/apps/index.md +++ b/doc/book/connect/apps/index.md @@ -54,7 +54,7 @@ garage bucket allow nextcloud --read --write --key nextcloud-key Now edit your Nextcloud configuration file to enable object storage. On my installation, the config. file is located at the following path: `/var/www/nextcloud/config/config.php`. -We will add a new root key to the `$CONFIG` dictionnary named `objectstore`: +We will add a new root key to the `$CONFIG` dictionary named `objectstore`: ```php secret: - endpoint: garage:3900 # publically accessible endpoint of your garage instance + endpoint: garage:3900 # publicly accessible endpoint of your garage instance region: garage bucket: use_path_style: true @@ -730,7 +730,7 @@ Pleroma have an internal migration tool that can encounter some fatal error So, use [your best tool](https://garagehq.deuxfleurs.fr/documentation/connect/cli/) to sync `/var/lib/pleroma/uploads/` in your S3. -Then, to avoid some non existant problem (just in case of), run this command +Then, to avoid some non existent problem (just in case of), run this command ```bash while true diff --git a/doc/book/connect/cli.md b/doc/book/connect/cli.md index 8329f0be..f52cc205 100644 --- a/doc/book/connect/cli.md +++ b/doc/book/connect/cli.md @@ -41,7 +41,7 @@ Some commands: # list buckets mc ls garage/ -# list objets in a bucket +# list objects in a bucket mc ls garage/my_files # copy from your filesystem to garage @@ -218,7 +218,7 @@ Within Cyberduck, a available within the `Preferences -> Profiles` section. This can enabled and then connections to Garage may be configured. -### Instuctions for the CLI +### Instructions for the CLI To configure duck (Cyberduck's CLI tool), start by creating its folder hierarchy: diff --git a/doc/book/connect/repositories.md b/doc/book/connect/repositories.md index 537b02e7..0ae79b1e 100644 --- a/doc/book/connect/repositories.md +++ b/doc/book/connect/repositories.md @@ -201,11 +201,9 @@ on the binary cache, the client will download the result from the cache instead ### Channels -Channels additionnaly serve Nix definitions, ie. a `.nix` file referencing +Channels additionally serve Nix definitions, ie. a `.nix` file referencing all the derivations you want to serve. ## Gitlab *External link:* [Gitlab Documentation > Object storage](https://docs.gitlab.com/ee/administration/object_storage.html) - - diff --git a/doc/book/cookbook/ansible.md b/doc/book/cookbook/ansible.md index 58457881..8d86a7d1 100644 --- a/doc/book/cookbook/ansible.md +++ b/doc/book/cookbook/ansible.md @@ -13,7 +13,7 @@ have published Ansible roles. We list them and compare them below. | **Runtime** | Systemd | Docker | Systemd | | **Target OS** | Any Linux | Any Linux | Any Linux | | **Architecture** | amd64, arm64, i686 | amd64, arm64 | arm64, arm, 386, amd64 | -| **Additional software** | None | Traefik | Ngnix and Keepalived (optional) | +| **Additional software** | None | Traefik | Nginx and Keepalived (optional) | | **Automatic node connection** | ❌ | ✅ | ✅ | | **Layout management** | ❌ | ✅ | ✅ | | **Manage buckets & keys** | ❌ | ✅ (basic) | ✅ | diff --git a/doc/book/cookbook/encryption.md b/doc/book/cookbook/encryption.md index bfbea0ec..13da4bd7 100644 --- a/doc/book/cookbook/encryption.md +++ b/doc/book/cookbook/encryption.md @@ -33,7 +33,7 @@ by adding encryption at different levels. We would be very curious to know your needs and thougs about ideas such as encryption practices and things like key management, as we want Garage to be a -serious base platform for the developpment of secure, encrypted applications. +serious base platform for the development of secure, encrypted applications. Do not hesitate to come talk to us if you have any thoughts or questions on the subject. @@ -59,7 +59,7 @@ For standard S3 API requests, Garage does not encrypt data at rest by itself. For the most generic at rest encryption of data, we recommend setting up your storage partitions on encrypted LUKS devices. -If you are developping your own client software that makes use of S3 storage, +If you are developing your own client software that makes use of S3 storage, we recommend implementing data encryption directly on the client side and never transmitting plaintext data to Garage. This makes it easy to use an external untrusted storage provider if necessary. @@ -108,14 +108,14 @@ Protects against the following threats: - Stolen HDD -Crucially, does not protect againt malicious sysadmins or remote attackers that +Crucially, does not protect against malicious sysadmins or remote attackers that might gain access to your servers. Methods include full-disk encryption with tools such as LUKS. ## Encrypting data on the client side -Protects againt the following threats: +Protects against the following threats: - A honest-but-curious administrator - A malicious administrator that tries to corrupt your data diff --git a/doc/book/cookbook/exposing-websites.md b/doc/book/cookbook/exposing-websites.md index 9382a541..74a5613d 100644 --- a/doc/book/cookbook/exposing-websites.md +++ b/doc/book/cookbook/exposing-websites.md @@ -9,7 +9,7 @@ There are three methods to expose buckets as website: 1. using the PutBucketWebsite S3 API call, which is allowed for access keys that have the owner permission bit set -2. from the Garage CLI, by an adminstrator of the cluster +2. from the Garage CLI, by an administrator of the cluster 3. using the Garage administration API diff --git a/doc/book/cookbook/from-source.md b/doc/book/cookbook/from-source.md index d8cc01f7..04b84aef 100644 --- a/doc/book/cookbook/from-source.md +++ b/doc/book/cookbook/from-source.md @@ -25,7 +25,7 @@ sudo apt-get install build-essential The primary location for Garage's source code is the [Forgejo repository](https://git.deuxfleurs.fr/Deuxfleurs/garage), which contains all of the released versions as well as the code -for the developpement of the next version. +for the development of the next version. Clone the repository and enter it as follows: @@ -41,7 +41,7 @@ git tag # List available tags git checkout v0.8.0 # Change v0.8.0 with the version you wish to build ``` -Otherwise you will be building a developpement build from the `main` branch +Otherwise you will be building a development build from the `main` branch that includes all of the changes to be released in the next version. Be careful that such a build might be unstable or contain bugs, and could be incompatible with nodes that run stable versions of Garage. diff --git a/doc/book/cookbook/kubernetes.md b/doc/book/cookbook/kubernetes.md index 9673340b..0f1e4aaf 100644 --- a/doc/book/cookbook/kubernetes.md +++ b/doc/book/cookbook/kubernetes.md @@ -47,7 +47,7 @@ All possible configuration values can be found with: helm show values ./garage ``` -This is an example `values.overrride.yaml` for deploying in a microk8s cluster with a https s3 api ingress route: +This is an example `values.override.yaml` for deploying in a microk8s cluster with a https s3 api ingress route: ```yaml garage: diff --git a/doc/book/cookbook/reverse-proxy.md b/doc/book/cookbook/reverse-proxy.md index d0f0c2bd..ffa8252c 100644 --- a/doc/book/cookbook/reverse-proxy.md +++ b/doc/book/cookbook/reverse-proxy.md @@ -272,7 +272,7 @@ Add the following configuration section [to compress response](https://doc.traef ### Add caching response -Traefik's caching middleware is only available on [entreprise version](https://doc.traefik.io/traefik-enterprise/middlewares/http-cache/), however the freely-available [Souin plugin](https://github.com/darkweak/souin#tr%C3%A6fik-container) can also do the job. (section to be completed) +Traefik's caching middleware is only available on [enterprise version](https://doc.traefik.io/traefik-enterprise/middlewares/http-cache/), however the freely-available [Souin plugin](https://github.com/darkweak/souin#tr%C3%A6fik-container) can also do the job. (section to be completed) ### Complete example diff --git a/doc/book/cookbook/systemd.md b/doc/book/cookbook/systemd.md index ebff8c15..820a47bf 100644 --- a/doc/book/cookbook/systemd.md +++ b/doc/book/cookbook/systemd.md @@ -38,7 +38,7 @@ WantedBy=multi-user.target id is dynamically allocated by systemd (set with `DynamicUser=true`). It cannot access (read or write) home folders (`/home`, `/root` and `/run/user`), the rest of the filesystem can only be read but not written, only the path seen as -`/var/lib/garage` is writable as seen by the service. Additionnaly, the process +`/var/lib/garage` is writable as seen by the service. Additionally, the process can not gain new privileges over time. For this to work correctly, your `garage.toml` must be set with diff --git a/doc/book/design/_index.md b/doc/book/design/_index.md index 5881ab8f..e7098dc8 100644 --- a/doc/book/design/_index.md +++ b/doc/book/design/_index.md @@ -10,7 +10,7 @@ perspective. It will allow you to understand if Garage is a good fit for you, how to better use it, how to contribute to it, what can Garage could and could not do, etc. -- **[Goals and use cases](@/documentation/design/goals.md):** This page explains why Garage was concieved and what practical use cases it targets. +- **[Goals and use cases](@/documentation/design/goals.md):** This page explains why Garage was conceived and what practical use cases it targets. - **[Related work](@/documentation/design/related-work.md):** This pages presents the theoretical background on which Garage is built, and describes other software storage solutions and why they didn't work for us. @@ -31,5 +31,3 @@ We love to talk and hear about Garage, that's why we keep a log here: - [(en, 2021-04-28) Distributed object storage is centralised](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/b1f60579a13d3c5eba7f74b1775c84639ea9b51a/doc/talks/2021-04-28_spirals-team/talk.pdf) - [(fr, 2020-12-02) Garage : jouer dans la cour des grands quand on est un hébergeur associatif](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/b1f60579a13d3c5eba7f74b1775c84639ea9b51a/doc/talks/2020-12-02_wide-team/talk.pdf) - - diff --git a/doc/book/design/benchmarks/index.md b/doc/book/design/benchmarks/index.md index 79cc5d62..2df916e0 100644 --- a/doc/book/design/benchmarks/index.md +++ b/doc/book/design/benchmarks/index.md @@ -15,14 +15,14 @@ The more a user request will require intra-cluster requests to complete, the mor This is especially true for sequential requests: requests that must wait the result of another request to be sent. We designed Garage without consensus algorithms (eg. Paxos or Raft) to minimize the number of sequential and parallel requests. -This serie of benchmarks quantifies the impact of this design choice. +This series of benchmarks quantifies the impact of this design choice. ### On a simple simulated network We start with a controlled environment, all the instances are running on the same (powerful enough) machine. -To control the network latency, we simulate the network with [mknet](https://git.deuxfleurs.fr/trinity-1686a/mknet) (a tool we developped, based on `tc` and the linux network stack). -To mesure S3 endpoints latency, we use our own tool [s3lat](https://git.deuxfleurs.fr/quentin/s3lat/) to observe only the intra-cluster latency and not some contention on the nodes (CPU, RAM, disk I/O, network bandwidth, etc.). +To control the network latency, we simulate the network with [mknet](https://git.deuxfleurs.fr/trinity-1686a/mknet) (a tool we developed, based on `tc` and the linux network stack). +To measure S3 endpoints latency, we use our own tool [s3lat](https://git.deuxfleurs.fr/quentin/s3lat/) to observe only the intra-cluster latency and not some contention on the nodes (CPU, RAM, disk I/O, network bandwidth, etc.). Compared to other benchmark tools, S3Lat sends only one (small) request at the same time and measures its latency. We selected 5 standard endpoints that are often in the critical path: ListBuckets, ListObjects, GetObject, PutObject and RemoveObject. @@ -32,7 +32,7 @@ In this first benchmark, we consider 5 instances that are located in a different Compared to garage, minio latency drastically increases on 3 endpoints: GetObject, PutObject, RemoveObject. -We suppose that these requests on minio make transactions over Raft, involving 4 sequential requests: 1) sending the message to the leader, 2) having the leader dispatch it to the other nodes, 3) waiting for the confirmation of followers and finally 4) commiting it. With our current configuration, one Raft transaction will take around 400 ms. GetObject seems to correlate to 1 transaction while PutObject and RemoveObject seems to correlate to 2 or 3. Reviewing minio code would be required to confirm this hypothesis. +We suppose that these requests on minio make transactions over Raft, involving 4 sequential requests: 1) sending the message to the leader, 2) having the leader dispatch it to the other nodes, 3) waiting for the confirmation of followers and finally 4) committing it. With our current configuration, one Raft transaction will take around 400 ms. GetObject seems to correlate to 1 transaction while PutObject and RemoveObject seems to correlate to 2 or 3. Reviewing minio code would be required to confirm this hypothesis. Conversely, garage uses an architecture similar to DynamoDB and never require global cluster coordination to answer a request. Instead, garage can always contact the right node in charge of the requested data, and can answer in as low as one request in the case of GetObject and PutObject. We also observed that Garage latency, while often lower to minio, is more dispersed: garage is still in beta and has not received any performance optimization yet. @@ -50,7 +50,7 @@ We plot a similar graph as before: This new graph is very similar to the one before, neither minio or garage seems to benefit from this new topology, but they also do not suffer from it. -Considering garage, this is expected: nodes in the same DC are put in the same zone, and then data are spread on different zones for data resiliency and availaibility. +Considering garage, this is expected: nodes in the same DC are put in the same zone, and then data are spread on different zones for data resiliency and availability. Then, in the default mode, requesting data requires to query at least 2 zones to be sure that we have the most up to date information. These requests will involve at least one inter-DC communication. In other words, we prioritize data availability and synchronization over raw performances. diff --git a/doc/book/design/internals.md b/doc/book/design/internals.md index 8e3c214e..81a11854 100644 --- a/doc/book/design/internals.md +++ b/doc/book/design/internals.md @@ -94,7 +94,7 @@ delete a tombstone, the following condition has to be met: - All nodes responsible for storing this entry are aware of the existence of the tombstone, i.e. they cannot hold another version of the entry that is - superseeded by the tombstone. This ensures that deleting the tombstone is + superseded by the tombstone. This ensures that deleting the tombstone is safe and that no deleted value will come back in the system. Garage uses atomic database operations (such as compare-and-swap and @@ -141,4 +141,3 @@ rebalance of data, this would have led to the disk utilization to explode during the rebalancing, only to shrink again after 24 hours. The 10-minute delay is a compromise that gives good security while not having this problem of disk space explosion on rebalance. - diff --git a/doc/book/design/related-work.md b/doc/book/design/related-work.md index 84e66c4e..a8461803 100644 --- a/doc/book/design/related-work.md +++ b/doc/book/design/related-work.md @@ -37,7 +37,7 @@ However, Amazon S3 source code is not open but alternatives were proposed. We identified Minio, Pithos, Swift and Ceph. Minio/Ceph enforces a total order, so properties similar to a (relaxed) filesystem. Swift and Pithos are probably the most similar to AWS S3 with their consistent hashing ring. -However Pithos is not maintained anymore. More precisely the company that published Pithos version 1 has developped a second version 2 but has not open sourced it. +However Pithos is not maintained anymore. More precisely the company that published Pithos version 1 has developed a second version 2 but has not open sourced it. Some tests conducted by the [ACIDES project](https://acides.org/) have shown that Openstack Swift consumes way more resources (CPU+RAM) that we can afford. Furthermore, people developing Swift have not designed their software for geo-distribution. There were many attempts in research too. I am only thinking to [LBFS](https://pdos.csail.mit.edu/papers/lbfs:sosp01/lbfs.pdf) that was used as a basis for Seafile. But none of them have been effectively implemented yet. @@ -63,7 +63,7 @@ Due to its industry oriented design, Ceph is also far from being *Simple* to ope In a certain way, Ceph and MinIO are closer together than they are from Garage or OpenStack Swift. **[Pithos](https://github.com/exoscale/pithos):** -Pithos has been abandonned and should probably not used yet, in the following we explain why we did not pick their design. +Pithos has been abandoned and should probably not used yet, in the following we explain why we did not pick their design. Pithos was relying as a S3 proxy in front of Cassandra (and was working with Scylla DB too). From its designers' mouth, storing data in Cassandra has shown its limitations justifying the project abandonment. They built a closed-source version 2 that does not store blobs in the database (only metadata) but did not communicate further on it. diff --git a/doc/book/development/release-process.md b/doc/book/development/release-process.md index 0c6701c0..476404f3 100644 --- a/doc/book/development/release-process.md +++ b/doc/book/development/release-process.md @@ -23,7 +23,7 @@ This logic is defined in `nix/build_index.nix`. For each commit, we first pass the code to a formatter (rustfmt) and a linter (clippy). Then we try to build it in debug mode and run both unit tests and our integration tests. -Additionnaly, when releasing, our integration tests are run on the release build for amd64 and i686. +Additionally, when releasing, our integration tests are run on the release build for amd64 and i686. ## Generated Artifacts @@ -32,7 +32,7 @@ We generate the following binary artifacts for now: - **os**: linux - **format**: static binary, docker container -Additionnaly we also build two web pages and one JSON document: +Additionally we also build two web pages and one JSON document: - the documentation (this website) - [the release page](https://garagehq.deuxfleurs.fr/_releases.html) - [the release list in JSON format](https://garagehq.deuxfleurs.fr/_releases.json) @@ -67,7 +67,7 @@ nix copy --to 's3://nix?endpoint=garage.deuxfleurs.fr®ion=garage&secret-key=/ The previous command will only send the built package and not its dependencies. In the case of our CI pipeline, we want to cache all intermediate build steps as well. This can be done using this quite involved command (here as an example -for the `pkgs.amd64.relase` package): +for the `pkgs.amd64.release` package): ```bash nix copy -j8 \ @@ -174,5 +174,3 @@ drone sign --save Deuxfleurs/garage ``` Looking at the file, you will see that most of the commands are `nix-shell` and `nix-build` commands with various parameters. - - diff --git a/doc/book/operations/layout.md b/doc/book/operations/layout.md index 667e89d2..a0b2f31d 100644 --- a/doc/book/operations/layout.md +++ b/doc/book/operations/layout.md @@ -242,7 +242,7 @@ dc3 Tags Partitions Capacity Usable capacity TOTAL 256 (256 unique) 2.0 GB 1000.0 MB (50.0%) ``` -As we can see, the node that was moved to `dc3` (node4) is only used at 25% (approximatively), +As we can see, the node that was moved to `dc3` (node4) is only used at 25% (approximately), whereas the node that was already in `dc3` (node3) is used at 75%. This can be explained by the following: @@ -260,7 +260,7 @@ This can be explained by the following: data can be removed to be moved to node1. - Garage will move data in equal proportions from all possible sources, in this - case it means that it will tranfer 25% of the entire data set from node3 to + case it means that it will transfer 25% of the entire data set from node3 to node1 and another 25% from node4 to node1. This explains why node3 ends with 75% utilization (100% from before minus 25% diff --git a/doc/book/operations/multi-hdd.md b/doc/book/operations/multi-hdd.md index 1cbcd805..c21b73d7 100644 --- a/doc/book/operations/multi-hdd.md +++ b/doc/book/operations/multi-hdd.md @@ -40,7 +40,7 @@ First of all, Garage divides the set of all possible block hashes in a fixed number of slices (currently 1024), and assigns to each slice a primary storage location among the specified data directories. The number of slices having their primary location in each data directory -is proportionnal to the capacity specified in the config file. +is proportional to the capacity specified in the config file. When Garage receives a block to write, it will always write it in the primary directory of the slice that contains its hash. diff --git a/doc/book/operations/upgrading.md b/doc/book/operations/upgrading.md index a3d2bcf5..26007dbe 100644 --- a/doc/book/operations/upgrading.md +++ b/doc/book/operations/upgrading.md @@ -56,7 +56,7 @@ From a high level perspective, a major upgrade looks like this: 10. Enable API access (reverse step 1) 11. Monitor your cluster while load comes back, check that all your applications are happy with this new version -### Major upgarades with minimal downtime +### Major upgrades with minimal downtime There is only one operation that has to be coordinated cluster-wide: the switch of one version of the internal RPC protocol to the next. This means that an upgrade with very limited downtime can simply be performed from one major version to the next by restarting all nodes diff --git a/doc/book/reference-manual/configuration.md b/doc/book/reference-manual/configuration.md index 642a16a1..12e39dbd 100644 --- a/doc/book/reference-manual/configuration.md +++ b/doc/book/reference-manual/configuration.md @@ -372,7 +372,7 @@ Performance characteristics of the different DB engines are as follows: not recommended. - Keys in LMDB are limited to 511 bytes. This limit translates to limits on - object keys in S3 and sort keys in K2V that are limted to 479 bytes. + object keys in S3 and sort keys in K2V that are limited to 479 bytes. - **Sqlite:** Garage supports Sqlite as an alternative storage backend for metadata, which does not have the issues listed above for LMDB. Sqlite is @@ -396,7 +396,7 @@ garage convert-db -a -i \ ``` Make sure to specify the full database path as presented in the table above -(third colummn), and not just the path to the metadata directory. +(third column), and not just the path to the metadata directory. #### `metadata_fsync` {#metadata_fsync} @@ -554,7 +554,7 @@ awaits for one of the `block_max_concurrent_reads` slots to be available slot, it reads the entire block file to RAM and frees the slot as soon as the block file is finished reading. Only after the slot is released will the block's data start being transferred over the network. If the request fails to -acquire a reading slot wihtin 15 seconds, it fails with a timeout error. +acquire a reading slot within 15 seconds, it fails with a timeout error. Timeout events can be monitored through the `block_read_semaphore_timeouts` metric in Prometheus: a non-zero number of such events indicates an I/O bottleneck on HDD read speed. @@ -617,11 +617,11 @@ storing the secret as the `GARAGE_RPC_SECRET_FILE` environment variable. #### `rpc_bind_addr` {#rpc_bind_addr} -The address and port on which to bind for inter-cluster communcations -(reffered to as RPC for remote procedure calls). +The address and port on which to bind for inter-cluster communications +(referred to as RPC for remote procedure calls). The port specified here should be the same one that other nodes will used to contact the node, even in the case of a NAT: the NAT should be configured to forward the external -port number to the same internal port nubmer. This means that if you have several nodes running +port number to the same internal port number. This means that if you have several nodes running behind a NAT, they should each use a different RPC port number. #### `rpc_bind_outgoing` (since `v0.9.2`) {#rpc_bind_outgoing} @@ -784,14 +784,14 @@ manually. #### `api_bind_addr` {#s3_api_bind_addr} The IP and port on which to bind for accepting S3 API calls. -This endpoint does not suport TLS: a reverse proxy should be used to provide it. +This endpoint does not support TLS: a reverse proxy should be used to provide it. Alternatively, since `v0.8.5`, a path can be used to create a unix socket with 0222 mode. #### `s3_region` {#s3_region} -Garage will accept S3 API calls that are targetted to the S3 region defined here. -API calls targetted to other regions will fail with a AuthorizationHeaderMalformed error +Garage will accept S3 API calls that are targeted to the S3 region defined here. +API calls targeted to other regions will fail with a AuthorizationHeaderMalformed error message that redirects the client to the correct region. #### `root_domain` {#s3_root_domain} @@ -799,7 +799,7 @@ message that redirects the client to the correct region. The optional suffix to access bucket using vhost-style in addition to path-style request. Note path-style requests are always enabled, whether or not vhost-style is configured. Configuring vhost-style S3 required a wildcard DNS entry, and possibly a wildcard TLS certificate, -but might be required by softwares not supporting path-style requests. +but might be required by software not supporting path-style requests. If `root_domain` is `s3.garage.eu`, a bucket called `my-bucket` can be interacted with using the hostname `my-bucket.s3.garage.eu`. @@ -815,7 +815,7 @@ behaviour of this module. The IP and port on which to bind for accepting HTTP requests to buckets configured for website access. -This endpoint does not suport TLS: a reverse proxy should be used to provide it. +This endpoint does not support TLS: a reverse proxy should be used to provide it. Alternatively, since `v0.8.5`, a path can be used to create a unix socket with 0222 mode. @@ -888,7 +888,7 @@ You can use any random string for this value. We recommend generating a random t If this is set to `true`, accessing the metrics endpoint will always require an access token. Valid tokens include the `metrics_token` if it is set, -and admin API token defined dynamicaly in Garage which have +and admin API token defined dynamically in Garage which have the `Metrics` endpoint in their scope. #### `trace_sink` {#admin_trace_sink} diff --git a/doc/book/reference-manual/features.md b/doc/book/reference-manual/features.md index a74b1467..aa801704 100644 --- a/doc/book/reference-manual/features.md +++ b/doc/book/reference-manual/features.md @@ -46,7 +46,7 @@ to select the replication mode best suited to your use case (hint: in most cases ### Compression and deduplication -All data stored in Garage is deduplicated, and optionnally compressed using +All data stored in Garage is deduplicated, and optionally compressed using Zstd. Objects uploaded to Garage are chunked in blocks of constant sizes (see [`block_size`](@/documentation/reference-manual/configuration.md#block_size)), and the hashes of individual blocks are used to dispatch them to storage nodes @@ -84,13 +84,13 @@ exposing the same content under different domain names. Garage also supports bucket aliases which are local to a single user: this allows different users to have different buckets with the same name, thus avoiding naming collisions. -This can be helpfull for instance if you want to write an application that creates per-user buckets with always the same name. +This can be helpful for instance if you want to write an application that creates per-user buckets with always the same name. This feature is totally invisible to S3 clients and does not break compatibility with AWS. ### Cluster administration API -Garage provides a fully-fledged REST API to administer your cluster programatically. +Garage provides a fully-fledged REST API to administer your cluster programmatically. Functionality included in the admin API include: setting up and monitoring cluster nodes, managing access credentials, and managing storage buckets and bucket aliases. A full reference of the administration API is available [here](@/documentation/reference-manual/admin-api.md). @@ -100,7 +100,7 @@ A full reference of the administration API is available [here](@/documentation/r Garage makes some internal metrics available in the Prometheus data format, which allows you to build interactive dashboards to visualize the load and internal state of your storage cluster. -For developpers and performance-savvy administrators, +For developers and performance-savvy administrators, Garage also supports exporting traces of what it does internally in OpenTelemetry format. This allows to monitor the time spent at various steps of the processing of requests, in order to detect potential performance bottlenecks. diff --git a/doc/book/reference-manual/k2v.md b/doc/book/reference-manual/k2v.md index f8e003d9..a0eaf064 100644 --- a/doc/book/reference-manual/k2v.md +++ b/doc/book/reference-manual/k2v.md @@ -19,7 +19,7 @@ The specification of the K2V API can be found [here](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/commit/f8be15c37db857e177d543de7be863692628d567/doc/drafts/k2v-spec.md). This document also includes a high-level overview of K2V's design. -The K2V API uses AWSv4 signatures for authentification, same as the S3 API. +The K2V API uses AWSv4 signatures for authentication, same as the S3 API. The AWS region used for signature calculation is always the same as the one defined for the S3 API in the config file. @@ -55,4 +55,3 @@ cargo build --features cli --bin k2v-cli The CLI utility is self-documented, run `k2v-cli --help` to learn how to use it. There is also a short README.md in the `src/k2v-client` folder with some instructions. - diff --git a/doc/book/reference-manual/s3-compatibility.md b/doc/book/reference-manual/s3-compatibility.md index b869b6f4..c44a7b1a 100644 --- a/doc/book/reference-manual/s3-compatibility.md +++ b/doc/book/reference-manual/s3-compatibility.md @@ -45,7 +45,7 @@ we suppose that OpenIO supports presigned URLs. All endpoints that are missing on Garage will return a 501 Not Implemented. Some `x-amz-` headers are not implemented. -### Core endoints +### Core endpoints | Endpoint | Garage | [Openstack Swift](https://docs.openstack.org/swift/latest/s3_compat.html) | [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/s3/) | [Riak CS](https://docs.riak.com/riak/cs/2.1.1/references/apis/storage/s3/index.html) | [OpenIO](https://docs.openio.io/latest/source/arch-design/s3_compliancy.html) | |------------------------------|----------------------------------|-----------------|---------------|---------|-----| @@ -135,12 +135,12 @@ If you need this feature, please [share your use case in our dedicated issue](ht **PutBucketLifecycleConfiguration:** The only actions supported are `AbortIncompleteMultipartUpload` and `Expiration` (without the `ExpiredObjectDeleteMarker` field). All other operations are dependent on -either bucket versionning or storage classes which Garage currently does not +either bucket versioning or storage classes which Garage currently does not implement. The deprecated `Prefix` member directly in the the `Rule` structure/XML tag is not supported, specified prefixes must be inside the `Filter` structure/XML tag. -**GetBucketVersioning:** Stub implementation which always returns "versionning not enabled", since Garage does not yet support bucket versionning. +**GetBucketVersioning:** Stub implementation which always returns "versioning not enabled", since Garage does not yet support bucket versioning. ### Replication endpoints @@ -155,7 +155,7 @@ Please open an issue if you have a use case for replication. *Note: Ceph documentation briefly says that Ceph supports [replication through the S3 API](https://docs.ceph.com/en/latest/radosgw/multisite-sync-policy/#s3-replication-api) but with some limitations. -Additionaly, replication endpoints are not documented in the S3 compatibility page so I don't know what kind of support we can expect.* +Additionally, replication endpoints are not documented in the S3 compatibility page so I don't know what kind of support we can expect.* ### Locking objects @@ -197,7 +197,7 @@ Please open an issue if you have a use case. ### Vendor specific endpoints -
Display Amazon specifc endpoints +
Display Amazon specific endpoints | Endpoint | Garage | [Openstack Swift](https://docs.openstack.org/swift/latest/s3_compat.html) | [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/s3/) | [Riak CS](https://docs.riak.com/riak/cs/2.1.1/references/apis/storage/s3/index.html) | [OpenIO](https://docs.openio.io/latest/source/arch-design/s3_compliancy.html) | @@ -234,4 +234,3 @@ Please open an issue if you have a use case. | [SelectObjectContent](https://docs.aws.amazon.com/AmazonS3/latest/API/API_SelectObjectContent.html) | ❌ Missing | ❌| ❌| ❌| ❌|
- diff --git a/doc/book/working-documents/compatibility-target.md b/doc/book/working-documents/compatibility-target.md index 630d15a5..2ed9dad4 100644 --- a/doc/book/working-documents/compatibility-target.md +++ b/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. diff --git a/doc/book/working-documents/design-draft.md b/doc/book/working-documents/design-draft.md index 8d3a31f0..de31ba0f 100644 --- a/doc/book/working-documents/design-draft.md +++ b/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 diff --git a/doc/book/working-documents/load-balancing.md b/doc/book/working-documents/load-balancing.md index 1a65fdd2..d6cbf4cc 100644 --- a/doc/book/working-documents/load-balancing.md +++ b/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 diff --git a/doc/book/working-documents/migration-07.md b/doc/book/working-documents/migration-07.md index 392c75a9..8631fa99 100644 --- a/doc/book/working-documents/migration-07.md +++ b/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/` diff --git a/doc/book/working-documents/testing-strategy.md b/doc/book/working-documents/testing-strategy.md index 3c29e47b..46550b81 100644 --- a/doc/book/working-documents/testing-strategy.md +++ b/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. - - diff --git a/doc/drafts/admin-api.md b/doc/drafts/admin-api.md index 18dfb627..778b4fa8 100644 --- a/doc/drafts/admin-api.md +++ b/doc/drafts/admin-api.md @@ -176,7 +176,7 @@ Returns the cluster's current health in JSON format, with the following variable - degraded: Garage node is not connected to all storage nodes, but a quorum of write nodes is available for all partitions - unavailable: a quorum of write nodes is not available for some partitions - `knownNodes`: the number of nodes this Garage node has had a TCP connection to since the daemon started -- `connectedNodes`: the nubmer of nodes this Garage node currently has an open connection to +- `connectedNodes`: the number of nodes this Garage node currently has an open connection to - `storageNodes`: the number of storage nodes currently registered in the cluster layout - `storageNodesOk`: the number of storage nodes to which a connection is currently open - `partitions`: the total number of partitions of the data (currently always 256) @@ -379,7 +379,7 @@ Example response: ] ``` -#### GetKeyInfo `GET /v2/GetKeyInfo?id=` +#### GetKeyInfo `GET /v2/GetKeyInfo?id=` #### GetKeyInfo `GET /v2/GetKeyInfo?search=` Returns information about the requested API access key. @@ -388,7 +388,7 @@ If `id` is set, the key is looked up using its exact identifier (faster). If `search` is set, the key is looked up using its name or prefix of identifier (slower, all keys are enumerated to do this). -Optionnally, the query parameter `showSecretKey=true` can be set to reveal the +Optionally, the query parameter `showSecretKey=true` can be set to reveal the associated secret access key. Example response: @@ -487,7 +487,7 @@ Request body format: This returns the key info in the same format as the result of GetKeyInfo. -#### UpdateKey `POST /v2/UpdateKey?id=` +#### UpdateKey `POST /v2/UpdateKey?id=` Updates information about the specified API access key. @@ -509,7 +509,7 @@ The possible flags in `allow` and `deny` are: `createBucket`. This returns the key info in the same format as the result of GetKeyInfo. -#### DeleteKey `POST /v2/DeleteKey?id=` +#### DeleteKey `POST /v2/DeleteKey?id=` Deletes an API access key. diff --git a/doc/drafts/k2v-spec.md b/doc/drafts/k2v-spec.md index f9696717..b16628e2 100644 --- a/doc/drafts/k2v-spec.md +++ b/doc/drafts/k2v-spec.md @@ -35,7 +35,7 @@ Triples in K2V are constituted of three fields: partition key in which the client wants to read/delete lists of items - a sort key (`sk`), an utf8 string that defines the index of the triplet inside its - partition; triplets are uniquely idendified by their partition key + sort key + partition; triplets are uniquely identified by their partition key + sort key - a value (`v`), an opaque binary blob associated to the partition key + sort key; they are transmitted as binary when possible but in most case in the JSON API @@ -74,7 +74,7 @@ are obsoleted by the new write. **Basic insertion.** To insert a new value `v4` with context `[(node1, t2), (node2, t3)]`, in a simple case where there was no insertion in-between reading the value -mentionned above and writing `v4`, and supposing that node2 receives the +mentioned above and writing `v4`, and supposing that node2 receives the InsertItem query: - `node2` generates a timestamp `t4` such that `t4 > t3`. @@ -332,7 +332,7 @@ Inserts a single item. This request does not use JSON, the body is sent directly To supersede previous values, the HTTP header `X-Garage-Causality-Token` should be set to the causality token returned by a previous read on this key. This -header can be ommitted for the first writes to the key. +header can be omitted for the first writes to the key. Example query: @@ -397,7 +397,7 @@ smallest partition key that exists. It returns partition keys in increasing order, or decreasing order if `reverse` is set to `true`, and stops when either of the following conditions is met: -1. if `end` is specfied, the partition key `end` is reached or surpassed (if it +1. if `end` is specified, the partition key `end` is reached or surpassed (if it is reached exactly, it is not included in the result) 2. if `limit` is specified, `limit` partition keys have been listed @@ -491,7 +491,7 @@ the triplet is inserted for the first time, the causality token should be set to The value is expected to be a base64-encoded binary blob. The value `null` can also be used to delete the triplet while preserving causality information: this -allows to know if a delete has happenned concurrently with an insert, in which +allows to know if a delete has happened concurrently with an insert, in which case both are preserved and returned on reads (see below). Partition keys and sort keys are utf8 strings which are stored sorted by @@ -540,7 +540,7 @@ JSON struct with the following fields: For each of the searches, triplets are listed and returned separately. The semantics of `prefix`, `start`, `end`, `limit` and `reverse` are the same as for ReadIndex. The -additionnal parameter `singleItem` allows to get a single item, whose sort key +additional parameter `singleItem` allows to get a single item, whose sort key is the one given in `start`. Parameters `conflictsOnly` and `tombstones` control additional filters on the items that are returned. diff --git a/script/helm/garage/README.md b/script/helm/garage/README.md index 67626030..a16d05ba 100644 --- a/script/helm/garage/README.md +++ b/script/helm/garage/README.md @@ -29,7 +29,7 @@ S3-compatible object store for small self-hosted geo-distributed deployments | garage.dbEngine | string | `"lmdb"` | Can be changed for better performance on certain systems https://garagehq.deuxfleurs.fr/documentation/reference-manual/configuration/#db_engine | | garage.existingConfigMap | string | `""` | if not empty string, allow using an existing ConfigMap for the garage.toml, if set, ignores garage.toml | | garage.garageTomlString | string | `""` | String Template for the garage configuration if set, ignores above values. Values can be templated, see https://garagehq.deuxfleurs.fr/documentation/reference-manual/configuration/ | -| garage.kubernetesSkipCrd | bool | `false` | Set to true if you want to use k8s discovery but install the CRDs manually outside of the helm chart, for example if you operate at namespace level without cluster ressources | +| garage.kubernetesSkipCrd | bool | `false` | Set to true if you want to use k8s discovery but install the CRDs manually outside of the helm chart, for example if you operate at namespace level without cluster resources | | garage.replicationFactor | string | `"3"` | Default to 3 replicas, see the replication_factor section at https://garagehq.deuxfleurs.fr/documentation/reference-manual/configuration/#replication_factor | | garage.consistencyMode | string | `"consistent"` | Default to read-after-write consistency, see the consistency_mode section at https://garagehq.deuxfleurs.fr/documentation/reference-manual/configuration/#consistency_mode | | garage.metadataAutoSnapshotInterval | string | `""` | If this value is set, Garage will automatically take a snapshot of the metadata DB file at a regular interval and save it in the metadata directory. https://garagehq.deuxfleurs.fr/documentation/reference-manual/configuration/#metadata_auto_snapshot_interval | @@ -76,7 +76,7 @@ S3-compatible object store for small self-hosted geo-distributed deployments | persistence.enabled | bool | `true` | | | persistence.meta.hostPath | string | `"/var/lib/garage/meta"` | | | persistence.meta.size | string | `"100Mi"` | | -| podAnnotations | object | `{}` | additonal pod annotations | +| podAnnotations | object | `{}` | additional pod annotations | | podSecurityContext.fsGroup | int | `1000` | | | podSecurityContext.runAsGroup | int | `1000` | | | podSecurityContext.runAsNonRoot | bool | `true` | | diff --git a/script/jepsen.garage/README.md b/script/jepsen.garage/README.md index 50c7eb38..4a74471d 100644 --- a/script/jepsen.garage/README.md +++ b/script/jepsen.garage/README.md @@ -127,7 +127,7 @@ They are due to the download being interrupted in the middle (^C during first la Add `:force?` to the `cached-wget!` call in `daemon.clj` to re-download the binary, or restar the VMs to clear temporary files. -### In `jepsen.garage`: prefix wierdness +### In `jepsen.garage`: prefix weirdness In `store/garage set1/20231019T163358.615+0200`: @@ -146,12 +146,12 @@ and passing all values that were previously in the context (creds and prefix) as The reg2 test is our custom checker for CRDT read-after-write on individual object keys, acting as registers which can be updated. The test fails without the timestamp fix, which is expected as the clock scrambler will prevent nodes from having a correct ordering of objects. -With the timestamp fix (`--patch tsfix1`), the happenned-before relationship should at least be respected, meaning that when a PutObject call starts +With the timestamp fix (`--patch tsfix1`), the happened-before relationship should at least be respected, meaning that when a PutObject call starts after another PutObject call has ended, the second call should overwrite the value of the first call, and that value should not be readable by future GetObject calls. However, we observed inconsistencies even with the timestamp fix. -The inconsistencies seemed to always happenned after writing a nil value, which translates to a DeleteObject call +The inconsistencies seemed to always happened after writing a nil value, which translates to a DeleteObject call instead of a PutObject. By removing the possibility of writing nil values, therefore only doing PutObject calls, the issue disappears. There is therefore an issue to fix in DeleteObject.