Yes, you're right, documentation should be more detailed. Alasdair also pointed me to the format they use in cache.txt and verity.txt files. I'll update dedup.txt to comply with that format and include the information about on-disk structures and behavior in case of a power failure. Will send an updated documentation patch in some time. The short answer to your question is that we use device-mapper's persistent-data library for storing metadata. The library uses COW B-trees to provide atomicity, consistency, and durability. On REQ_FUA we commit transactions. The allocation of data blocks on a data device ensures that no old blocks are overwritten within a transaction. So, during a write operation, data blocks go straight to the disk, but they become visible only after the transaction is committed (i.e., if power fails in the middle of the transaction, one sees the old image of the device). I'll explain more details in the documentation patch. Thanks, Vasily On Tue, Apr 29, 2014 at 2:23 AM, Bart Van Assche <bvanassche@xxxxxxx> wrote: > On 04/29/14 00:03, Vasily Tarasov wrote: >> See the documentation patch for more details. > > Regarding that documentation: shouldn't the on-disk data structures be > documented ? Shouldn't it be documented how dm-dedup recovers from a > power failure ? Since different storage devices are used for data and > meta-data recovery from a power failure is nontrivial. How is it e.g. > guaranteed if a data block has been made persistent (e.g. via REQ_FUA) > and the refcount is increased for that data block that neither the data > nor the metadata for that data block is lost if a power failure occurs ? > > Bart. > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
