From dc995059aa63b06013dd482854a0019fa21e48c3 Mon Sep 17 00:00:00 2001 From: Alex Auvolat Date: Wed, 28 Feb 2024 13:43:30 +0100 Subject: [doc-dedup] mention deduplication and compression in features page --- doc/book/reference-manual/features.md | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/book/reference-manual') diff --git a/doc/book/reference-manual/features.md b/doc/book/reference-manual/features.md index e8ba9510..433efd44 100644 --- a/doc/book/reference-manual/features.md +++ b/doc/book/reference-manual/features.md @@ -55,6 +55,14 @@ and with various levels of consistency, in order to adapt to a variety of usage Read our reference page on [supported replication modes](@/documentation/reference-manual/configuration.md#replication_mode) to select the replication mode best suited to your use case (hint: in most cases, `replication_mode = "3"` is what you want). +### Compression and deduplication + +All data stored in Garage is deduplicated, and optionnally 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 +and to deduplicate them. + ### Web server for static websites A storage bucket can easily be configured to be served directly by Garage as a static web site. -- cgit v1.2.3 From 947973982d3e9876e1bee8534e63a8ffcd6c0d8d Mon Sep 17 00:00:00 2001 From: Alex Auvolat Date: Wed, 28 Feb 2024 13:45:30 +0100 Subject: [doc-dedup] fix #rpc_bind_outgoing anchor in config page --- doc/book/reference-manual/configuration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/book/reference-manual') diff --git a/doc/book/reference-manual/configuration.md b/doc/book/reference-manual/configuration.md index f1474613..af66c4b8 100644 --- a/doc/book/reference-manual/configuration.md +++ b/doc/book/reference-manual/configuration.md @@ -417,7 +417,7 @@ the node, even in the case of a NAT: the NAT should be configured to forward the port number to the same internal port nubmer. This means that if you have several nodes running behind a NAT, they should each use a different RPC port number. -#### `rpc_bind_outgoing` {#rpc_bind_outgoing} (since v0.9.2) +#### `rpc_bind_outgoing`(since v0.9.2) {#rpc_bind_outgoing} If enabled, pre-bind all sockets for outgoing connections to the same IP address used for listening (the IP address specified in `rpc_bind_addr`) before -- cgit v1.2.3 From a294dd9473fb47e142d0dbac7028481ff00f921e Mon Sep 17 00:00:00 2001 From: Alex Auvolat Date: Wed, 28 Feb 2024 13:48:45 +0100 Subject: [doc-dedup] reorder features, move no-RAFT down --- doc/book/reference-manual/features.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'doc/book/reference-manual') diff --git a/doc/book/reference-manual/features.md b/doc/book/reference-manual/features.md index 433efd44..f7014b26 100644 --- a/doc/book/reference-manual/features.md +++ b/doc/book/reference-manual/features.md @@ -37,17 +37,6 @@ A Garage cluster can very easily evolve over time, as storage nodes are added or Garage will automatically rebalance data between nodes as needed to ensure the desired number of copies. Read about cluster layout management [here](@/documentation/operations/layout.md). -### No RAFT slowing you down - -It might seem strange to tout the absence of something as a desirable feature, -but this is in fact a very important point! Garage does not use RAFT or another -consensus algorithm internally to order incoming requests: this means that all requests -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. - ### Several replication modes Garage supports a variety of replication modes, with 1 copy, 2 copies or 3 copies of your data, @@ -63,6 +52,17 @@ Zstd. Objects uploaded to Garage are chunked in blocks of constant sizes (see and the hashes of individual blocks are used to dispatch them to storage nodes and to deduplicate them. +### No RAFT slowing you down + +It might seem strange to tout the absence of something as a desirable feature, +but this is in fact a very important point! Garage does not use RAFT or another +consensus algorithm internally to order incoming requests: this means that all requests +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. + ### Web server for static websites A storage bucket can easily be configured to be served directly by Garage as a static web site. -- cgit v1.2.3