On Tue, May 06 2014 at 9:43am -0400, Vasily Tarasov <tarasov@xxxxxxxxxxx> wrote: > Interestingly, I can see 4, 5, and 7 in dm-devel's archive: > > https://www.redhat.com/archives/dm-devel/2014-April/author.html > > In any case, you can pull the patches from: > > git://git.fsl.cs.sunysb.edu/linux-dmdedup.git > > Branch: rfc-v1.1 > > Thanks for looking into this. Hi, I haven't been able to get to _really_ reviewing dm-dedup. It isn't anything against you guys.. I've just been quite busy with other tasks. I did start in on dm-dedup a month or so ago by staging a baseline of your work in a branch here: http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/log/?h=dm-dedup I found a few things that didn't look right, but they are more DM-specific mechanics and not anything to do with your approach for accomplishing dedup, see the FIXMEs I added to the documentation file in this commit: http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=dm-dedup&id=fed855928fba624c7a494db7519c37dcc7c9492d The reconstruct= param isn't needed. In both dm-thinp and dm-cache we use __superblock_all_zeroes to checks if the metadata device's superblock is all zeros. Ideally dm-dedup would do something comparable. I'm going to be on paternity leave until Sept. 8. It'd be great if Joe and/or Mikulas took some time to review dm-dedup but I'm not sure if they'll be able to. I do hope to be around to respond to emails periodically but my availability is TBD at this point. When I get back from leave I'll definitely make dm-dedup a priority if others don't beat me to it. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
