Question about the consistency operations in cowbtree backend

[Oliver-Luo]

I've found that we are using two kinds of techs to keep the file on disk consistent in the cowbtree backend, copy-on-write and transaction. To my understand, either of them could guarantee the consistency, so why us them at the same time?

After reading the codes under persistent-data(like dm-btree/dm-transaction-manager), I thought this problem may come from using these codes, since they are like a whole. If you choose to use dm-btree, you have to use dm-block-manager and dm-transaction-manager as well, which means transaction and copy-on-write are somehow like the "side effect" of choosing dm-btree. If that is true, then I think we could only use one of these two techs by using our own code, thus saving the other one's overhead. Is that right?

[sectorsize512]

Hi Oliver,

Dm-dedup core logic needs a key-value store like API to store its metadata (e.g., hash index and mapping). So, dm-btree was a logical choice because it provides a key-value API. Furthermore, dmdedup needs some transactional and consistency guarantees from its baceknds. And dm-btree provides these guarantees using dm-transaction-manager.

One could surely design a dm-dedup backend that uses dm-transaction-manager directly. But then the key-value store has to be implemented by the backend itself (e.g., like a table in DTD or anything else).

Best,
Vasily

[Oliver-Luo]

Hi Vasily,

Do you mean that we have to use the dm-transaction-manager to keep the IO shadowing feature of the cowbtree? As I understand, the last step, or the "commit" step of the cowbtree must be atomic to keep the consistency, so the dm-transaction-manager is used for that, right?

Yours,
Oliver