5 files changed, 53 insertions, 8 deletions
diff --git a/doc/book/connect/apps/index.md b/doc/book/connect/apps/index.md
index 4d556ff8..e2d007c3 100644
--- a/doc/book/connect/apps/index.md
+++ b/doc/book/connect/apps/index.md
@@ -36,7 +36,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.  
@@ -138,7 +138,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.  
@@ -252,7 +252,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
 ```
@@ -378,7 +378,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
 ```
diff --git a/doc/book/connect/backup.md b/doc/book/connect/backup.md
index f51dda30..97a89e36 100644
--- a/doc/book/connect/backup.md
+++ b/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
 ```
diff --git a/doc/book/connect/repositories.md b/doc/book/connect/repositories.md
index 4b14bb46..66365d64 100644
--- a/doc/book/connect/repositories.md
+++ b/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
diff --git a/doc/book/quick-start/_index.md b/doc/book/quick-start/_index.md
index f556eaa3..ce8cb217 100644
--- a/doc/book/quick-start/_index.md
+++ b/doc/book/quick-start/_index.md
@@ -206,7 +206,7 @@ one key can access multiple buckets, multiple keys can access one bucket.
 Create an API key using the following command:
 
 ```
-garage key new --name nextcloud-app-key
+garage key create nextcloud-app-key
 ```
 
 The output should look as follows:
diff --git a/doc/book/reference-manual/configuration.md b/doc/book/reference-manual/configuration.md
index 20a79aa6..1466850c 100644
--- a/doc/book/reference-manual/configuration.md
+++ b/doc/book/reference-manual/configuration.md
@@ -10,6 +10,8 @@ Here is an example `garage.toml` configuration file that illustrates all of the
 ```toml
 metadata_dir = "/var/lib/garage/meta"
 data_dir = "/var/lib/garage/data"
+metadata_fsync = true
+data_fsync = false
 
 db_engine = "lmdb"
 
@@ -130,6 +132,49 @@ convert-db -a <input db engine> -i <input db path> \
 Make sure to specify the full database path as presented in the table above,
 and not just the path to the metadata directory.
 
+### `metadata_fsync`
+
+Whether to enable synchronous mode for the database engine or not.
+This is disabled (`false`) by default.
+
+This reduces the risk of metadata corruption in case of power failures,
+at the cost of a significant drop in write performance,
+as Garage will have to pause to sync data to disk much more often
+(several times for API calls such as PutObject).
+
+Using this option reduces the risk of simultaneous metadata corruption on several
+cluster nodes, which could lead to data loss.
+
+If multi-site replication is used, this option is most likely not necessary, as
+it is extremely unlikely that two nodes in different locations will have a 
+power failure at the exact same time.
+
+(Metadata corruption on a single node is not an issue, the corrupted data file
+can always be deleted and reconstructed from the other nodes in the cluster.)
+
+Here is how this option impacts the different database engines:
+
+| Database | `metadata_fsync = false` (default) | `metadata_fsync = true`       |
+|----------|------------------------------------|-------------------------------|
+| Sled     | default options                    | *unsupported*                 |
+| Sqlite   | `PRAGMA synchronous = OFF`         | `PRAGMA synchronous = NORMAL` |
+| LMDB     | `MDB_NOMETASYNC` + `MDB_NOSYNC`    | `MDB_NOMETASYNC`              |
+
+Note that the Sqlite database is always ran in `WAL` mode (`PRAGMA journal_mode = WAL`).
+
+### `data_fsync`
+
+Whether to `fsync` data blocks and their containing directory after they are
+saved to disk.
+This is disabled (`false`) by default.
+
+This might reduce the risk that a data block is lost in rare
+situations such as simultaneous node losing power,
+at the cost of a moderate drop in write performance.
+
+Similarly to `metatada_fsync`, this is likely not necessary
+if geographical replication is used.
+
 ### `block_size`
 
 Garage splits stored objects in consecutive chunks of size `block_size`