Separate replication modes for metadata/data #720

New Issue

Open

opened 2024-02-18 20:51:37 +00:00 by yuka · 1 comment

yuka commented

2024-02-18 20:51:37 +00:00

Contributor

An idea about a replication mode that would not compromise too much on complexity (no erasure coding or anything), but still give the ability to have a reliable garage cluster with a bit less disk usage.
So basically I would split the replication count of metadata and data. So that there are three copies of the metadata, but only two copies of the data. Since the metadata includes a hash of the block, the third metadata node could be used as a tie breaker (and to confirm the read when one of the two nodes holding the data is offline, for providing read-after-write-consistency) while not requiring to save the whole block a third time. I wonder if you considered something like this already.

An idea about a replication mode that would not compromise too much on complexity (no erasure coding or anything), but still give the ability to have a reliable garage cluster with a bit less disk usage. So basically I would split the replication count of metadata and data. So that there are three copies of the metadata, but only two copies of the data. Since the metadata includes a hash of the block, the third metadata node could be used as a tie breaker (and to confirm the read when one of the two nodes holding the data is offline, for providing read-after-write-consistency) while not requiring to save the whole block a third time. I wonder if you considered something like this already.

lx commented

2024-02-19 08:30:52 +00:00

Owner

I think once we have #550 this would not be too hard. Supporting multiple replication modes / multiple layouts in a single cluster is the really hard part.