Next

.drone.yml

@@ -20,6 +20,7 @@ steps:
     image: nixpkgs/nix:nixos-22.05
     environment:
       GARAGE_TEST_INTEGRATION_EXE: result-bin/bin/garage
+      GARAGE_TEST_INTEGRATION_PATH: tmp-garage-integration
     commands:
       - nix-build --no-build-output --attr clippy.amd64 --argstr git_version ${DRONE_TAG:-$DRONE_COMMIT}
       - nix-build --no-build-output --attr test.amd64
@@ -31,8 +32,9 @@ steps:
       - ./result/bin/garage_util-*
       - ./result/bin/garage_web-*
       - ./result/bin/garage-*
-      - ./result/bin/integration-*
+      - ./result/bin/integration-* || (cat tmp-garage-integration/stderr.log; false)
       - rm result
+      - rm -rv tmp-garage-integration
 
   - name: integration tests
     image: nixpkgs/nix:nixos-22.05
@@ -63,11 +65,16 @@ steps:
       - nix-build --no-build-output --attr pkgs.amd64.release --argstr git_version ${DRONE_TAG:-$DRONE_COMMIT}
       - nix-shell --attr rust --run "./script/not-dynamic.sh result-bin/bin/garage"
 
-  - name: integration
+  - name: integration tests
     image: nixpkgs/nix:nixos-22.05
     commands:
       - nix-shell --attr integration --run ./script/test-smoke.sh || (cat /tmp/garage.log; false)
 
+  - name: upgrade tests
+    image: nixpkgs/nix:nixos-22.05
+    commands:
+      - nix-shell --attr integration --run "./script/test-upgrade.sh v0.8.4 x86_64-unknown-linux-musl" || (cat /tmp/garage.log; false)
+
   - name: push static binary
     image: nixpkgs/nix:nixos-22.05
     environment:
@@ -114,11 +121,16 @@ steps:
       - nix-build --no-build-output --attr pkgs.i386.release --argstr git_version ${DRONE_TAG:-$DRONE_COMMIT}
       - nix-shell --attr rust --run "./script/not-dynamic.sh result-bin/bin/garage"
 
-  - name: integration
+  - name: integration tests
     image: nixpkgs/nix:nixos-22.05
     commands:
       - nix-shell --attr integration --run ./script/test-smoke.sh || (cat /tmp/garage.log; false)
 
+  - name: upgrade tests
+    image: nixpkgs/nix:nixos-22.05
+    commands:
+      - nix-shell --attr integration --run "./script/test-upgrade.sh v0.8.4 i686-unknown-linux-musl" || (cat /tmp/garage.log; false)
+
   - name: push static binary
     image: nixpkgs/nix:nixos-22.05
     environment:
@@ -283,6 +295,6 @@ trigger:
 
 ---
 kind: signature
-hmac: ac09a5a8c82502f67271f93afa1e1e21ce66383b8e24a6deb26b285cc1c378ba
+hmac: 0c4b57eb4b27b7c6a6ff21ab87f0767fe3eb90f5d95d5cbcdccf794e9d2a5d86
 
 ...

doc/book/connect/apps/index.md

@@ -37,7 +37,7 @@ Second, we suppose you have created a key and a bucket.
 As a reminder, you can create a key for your nextcloud instance as follow:
 
 ```bash
-garage key new --name nextcloud-key
+garage key create nextcloud-key
 ```
 
 Keep the Key ID and the Secret key in a pad, they will be needed later.  
@@ -139,7 +139,7 @@ a reasonable trade-off for some instances.
 Create a key for Peertube:
 
 ```bash
-garage key new --name peertube-key
+garage key create peertube-key
 ```
 
 Keep the Key ID and the Secret key in a pad, they will be needed later.  
@@ -253,7 +253,7 @@ As such, your Garage cluster should be configured appropriately for good perform
 This is the usual Garage setup:
 
 ```bash
-garage key new --name mastodon-key
+garage key create mastodon-key
 garage bucket create mastodon-data
 garage bucket allow mastodon-data --read --write --key mastodon-key
 ```
@@ -379,7 +379,7 @@ Supposing you have a working synapse installation, you can add the module with p
 Now create a bucket and a key for your matrix instance (note your Key ID and Secret Key somewhere, they will be needed later):
 
 ```bash
-garage key new --name matrix-key
+garage key create matrix-key
 garage bucket create matrix
 garage bucket allow matrix --read --write --key matrix-key
 ```

doc/book/connect/backup.md

@@ -54,7 +54,7 @@ how to configure this.
 Create your key and bucket:
 
 ```bash
-garage key new my-key
+garage key create my-key
 garage bucket create backup
 garage bucket allow backup --read --write --key my-key
 ```

doc/book/connect/repositories.md

@@ -23,7 +23,7 @@ You can configure a different target for each data type (check `[lfs]` and `[att
 Let's start by creating a key and a bucket (your key id and secret will be needed later, keep them somewhere):
 
 ```bash
-garage key new --name gitea-key
+garage key create gitea-key
 garage bucket create gitea
 garage bucket allow gitea --read --write --key gitea-key
 ```
@@ -118,7 +118,7 @@ through another support, like a git repository.
 As a first step, we will need to create a bucket on Garage and enabling website access on it:
 
 ```bash
-garage key new --name nix-key
+garage key create nix-key
 garage bucket create nix.example.com
 garage bucket allow nix.example.com --read --write --key nix-key
 garage bucket website nix.example.com --allow

doc/book/cookbook/real-world.md

@@ -75,16 +75,11 @@ to store 2 TB of data in total.
 
 - For the metadata storage, Garage does not do checksumming and integrity
   verification on its own. If you are afraid of bitrot/data corruption,
-  put your metadata directory on a BTRFS partition. Otherwise, just use regular
+  put your metadata directory on a ZFS or BTRFS partition. Otherwise, just use regular
   EXT4 or XFS.
 
-- Having a single server with several storage drives is currently not very well
-  supported in Garage ([#218](https://git.deuxfleurs.fr/Deuxfleurs/garage/issues/218)).
-  For an easy setup, just put all your drives in a RAID0 or a ZFS RAIDZ array.
-  If you're adventurous, you can try to format each of your disk as
-  a separate XFS partition, and then run one `garage` daemon per disk drive,
-  or use something like [`mergerfs`](https://github.com/trapexit/mergerfs) to merge
-  all your disks in a single union filesystem that spreads load over them.
+- Servers with multiple HDDs are supported natively by Garage without resorting
+  to RAID, see [our dedicated documentation page](@/documentation/operations/multi-hdd.md).
 
 ## Get a Docker image
 

doc/book/operations/durability-repairs.md

@@ -91,6 +91,16 @@ is definitely lost, then there is no other choice than to declare your S3 object
 as unrecoverable, and to delete them properly from the data store. This can be done
 using the `garage block purge` command.
 
+## Rebalancing data directories
+
+In [multi-HDD setups](@/documentation/operations/multi-hdd.md), to ensure that
+data blocks are well balanced between storage locations, you may run a
+rebalance operation using `garage repair rebalance`. This is usefull when
+adding storage locations or when capacities of the storage locations have been
+changed.  Once this is finished, Garage will know for each block of a single
+possible location where it can be, which can increase access speed.  This
+operation will also move out all data from locations marked as read-only.
+
 
 # Metadata operations
 
@@ -114,4 +124,3 @@ in your cluster, you can run one of the following repair procedures:
 
 - `garage repair versions`: checks that all versions belong to a non-deleted object, and purges any orphan version
 - `garage repair block_refs`: checks that all block references belong to a non-deleted object version, and purges any orphan block reference (this will then allow the blocks to be garbage-collected)
-