[dm-devel] [PATCH RFCv2 01/10] dm-dedup: main data structures

[Vasily Tarasov]

Hi Mike, Vivek,

Sounds good, thanks for looking into this!

At this point we don't have a dedup_checker. Could you clarify a bit
on the main use case for a cheker? Sudden power loss or accidental
corruption of metadata/ data devices?

In dm-dedup, metadata is stored using dm's persistent-data library
(COW B-trees). Data blocks are written asynchronously with meta-data
but allocated sequentially. So, theoretically, on a sudden power loss
the state of a dm-dedup should remain consistent.

But if somebody corrupts metadata/data devices manually the checker
will help. Is it the main use case?

We'll definitely take a look into the verifier's code for thin and
cache targets and see how this applies to dm-dedup.

Thanks,
Vasily

On Wed, Nov 26, 2014 at 11:47 AM, Mike Snitzer <snitzer at redhat.com> wrote:
> On Wed, Nov 26 2014 at 11:36am -0500,
> Erez Zadok <ezk at fsl.cs.sunysb.edu> wrote:
>
>> Mike, Vivek,
>>
>> Thank you for the effort and especially for adding more man-power to
>> this review.  We know how busy you guys are so it’s understandable
>> that things can take a while to get started.  Either way, I’ve
>> instructed my students to give this project the highest priority,
>> especially once we receive comments from you.
>
> Great.  So along those lines have you guys worked on userspace tools
> that can verify/repair the ondisk metadata?
>
> That will be a prereq for upstream inclusion (at least for dm-dedup to
> become anything but "experimental").
>
> dm-cache and dm-thin targets have these types of tools
> (thin_{check,repair}, cache_{check,repair}, etc).  Upstream repo is here
> (misnamed, gets packaged into device-mapper-persistent-data rpm on
> Fedora, RHEL, CentOS, etc):
> https://github.com/jthornber/thin-provisioning-tools
>
> Mike
>