You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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).
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?
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?
The text was updated successfully, but these errors were encountered: