elek commented on pull request #920: URL: https://github.com/apache/hadoop-ozone/pull/920#issuecomment-630201297
Thanks to explain it @maobaolong > not sure if we should define a message StorageClass in the proto file which also contains replicationType and replicationFactor, Not exactly. My proposal to include only one "enum/int" in the proto file and remove replicationFactor and replicationType. For example use `1=STANDARAD` instead of `RATIS/THREE` in the proto file. The exact meaning of STANDARD(1) can be resolved on server side (and can be changed over time). > In fact, i have proved Ozone can write 2 replica directly through Ratis... I agree with your analyses about the effectiveness of `Ratis/THREE->Closed/TWO` or Ratis/ONE->Closed/TWO`. I was just not sure how is it possible to use TWO with Ratis. Do you use two nodes Ratis cluster? It has totally different availability guarantee than Ratis/THREE as there is no majority just full quorum. I guess it works only if you have two nodes all the time and It couldn't work with loosing any of the nodes. I am interested if you have more details to share... *In general*: I wouldn't like to block this effort. Based on the `storage-class` proposal this change is not required any more as it can be replaced with an even more generic approach (propagate only the ID of the storage-class instead of replication type / factor). I am more interested about the consensus about the long-term divergence (long-term = until the next release...), if you need this change immediately, I am not against it. ** Footnote **: Just some notes, not closely related. Yesterday I read the [paper of the ChubaoFs](https://arxiv.org/pdf/1911.03001v1.pdf) and it has very interesting approach. The motivation is different, but they two different kind of replications for different use cases: > The storage engine guarantees the strong consistencyamong the replicas through either primary-backup or Raft-based replication protocols. This design decision is basedon the observations that the former one is not suitable foroverwrite as the replication performance needs to be com-promised, and the latter one has write amplification issue asit introduces extra IO of writing the log files. With introducing storage-class AND using specific containers / replication (like Erasure Coded containers) our approach can be somewhat similar ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: ozone-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: ozone-issues-h...@hadoop.apache.org
