INode replication vs Block replication.

[xiang90]

There is a parameter called INodeReplication, which defines how many replica each INode is expected to have.

What is the plan for handling Block replication? For N copy, we can simply reuse the INodeReplication parameter. But when doing RS encoding for blocks, the replication factor does not make a lot of sense.

Another question is that, are we trying to replicate the block on the same node as the INode?

[jzelinskie]

I think we should just reframe this whole conversation to be a question about replication strategy in general. I'm fairly certain that the parameter you're talking about is already gone and replication is actually now a property of the ring. If you enable a replication on the ring and also RS for the block storage, there will be lots of redundancy. However, as you've pointed out, because of how the project is structured, block stores do not have access to the same information that the ring does and may end up replicating in unfortunate ways.

I think we need to do some research and discussion on the baseline of what our replication strategies should be. Spitballing some questions:

• Are we going to support configuring replication per-file/inode?
  • What are the pros and cons to doing so?
  • If so, how are we going to store and configure the replication?
    • Directory names like CNS
    • Extended file attributes
    • A configuration file in a language like YAML/JSON
• Are we going to support block-level replication?
• If we are going to support both, how are we going to reconcile interactions between the two?

[philips]

@barakmich is this bug still valid?

[xiang90]

I do not think this is still relevant.