> I added a few comments, my high level perspective is that it looks > like an approach for dealing with multiversioned extents which might > be a component of rados pool level point-in-time globally consistent > snapshots for purposes like rados pool level cross-cluster > replication. However, that sort of thing would require a great deal > of higher level support, so I'd consider the disk layout portion to be > out of scope for now. Is there another use case you are hoping to > address with this? Hi, sam. Thanks for reviewing the doc:-) The main focus of this initiative is about doing efficient replication/backup. Specifically, we intended to provide higher level modules, especially to rbd and cephfs, the ability to do very high rate snapshots (like one snapshot every 5 seconds or even multiple snapshots within a second) and efficient snapshot diff and export-diff. We thought, with this ability, upper level applications can achieve near real-time replication that can be compared to the common op-by-op replication, but with less overhead. Because it doesn't involve any extra replication-dedicated journal operations. And as multiple write operations' targeting extents may overlap with each other, even the op-by-op replication can also avoid extra journal operations, they inevitably replicate overlapped extents multiple times, while, in snapshot diff export, only the latest version of the overlapped extents need to be replicated. We thought maybe we can let upper layer applications to choose whether to replicate their data instead of doing the replication forcibly at the whole rados pool scale. Whether this approach can really achieve that goal and whether to do it is to be discussed, as we also realised that it may not be cost-effective with respect to the amount of development work:-) Thanks. _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
