change tracking with block-level granularity using md

change tracking with block-level granularity using md

[Thomas Knauth]

Hello list,

I am the author of the following paper

https://www.usenix.org/conference/lisa13/technical-sessions/papers/knauth

just presented at LISA 2013. Folks at the conference expressed
interested in seeing this merged into the official Linux kernel. I
would like to gauge your opinion of whether this has a chance to
actually be accepted.

The basic idea is to provide a mechanism to track changes at the block
device layer. I've based my prototype on dm-linear.c. The following
things were added:

(1) a bit vector (one bit per 4 KiB block) is used to track the changes.
(2) a pseudo-file in /proc, one per tracked device, exports the
changed block numbers

There are also two small user-space tools for convenient extraction
and merging of the modified blocks.

I'd be happy to hear your thoughts/concerns and answer questions. If I
get positive feedback, I'd prepare a patch (as outlined in
the kernel docs) and send it to the list for further dissection.

There also exists a bitbucket repository (
https://bitbucket.org/tknauth/devicemapper/ ) with all the data
related to the above paper. It also includes the code [1], albeit in
all its unpolished research hack glory.

Kind regards,
Thomas.

[1] patch file against old 3.2 kernel:
https://bitbucket.org/tknauth/devicemapper/src/ffe167007fb4c57f7b00d60ce32aa59ff4b66d61/code/dsync.diff?at=master

Re: change tracking with block-level granularity using md

[Hannes Reinecke]

On 12/18/2013 09:04 AM, Thomas Knauth wrote:
> Hello list,
> 
> I am the author of the following paper
> 
> https://www.usenix.org/conference/lisa13/technical-sessions/papers/knauth
> 
> just presented at LISA 2013. Folks at the conference expressed
> interested in seeing this merged into the official Linux kernel. I
> would like to gauge your opinion of whether this has a chance to
> actually be accepted.
> 
Well, you just implemented an asynchronous mirror with discrete
tools. Congratulations.
Using bitmaps for tracking modified blocks has been a standard
technique in RAID1 for ages.

(look for mdadm --write-behind and drivers/md/bitmap.c. It's not
actually _new_ ...)

Sorry for being sarcastic.

But nevertheless, your tool might actually be useful; tracking block
changes could have some benefit on other areas.

What you should be doing:
- Rename the thing (dm-linear is taken; maybe dm-bitmap ?)
- Use debugfs instead of /proc
- Proper formatting

And then send the code for review.

Or go for the full monty and break up dm-mirror to include your
bitmap code. But then you would need to come up with a way of
storing your bitmap on disk.
Which is where the _real_ fun starts.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: change tracking with block-level granularity using md

[Joe Thornber]

On Wed, Dec 18, 2013 at 09:04:17AM +0100, Thomas Knauth wrote:
> Hello list,
> 
> I am the author of the following paper
> 
> https://www.usenix.org/conference/lisa13/technical-sessions/papers/knauth

I've been working on a similar problem.  There's a new target called
dm-era taking shape here:

https://github.com/jthornber/linux-2.6/blob/era/drivers/md/dm-era-target.c

It uses bloom filters to track changed blocks.  Userland tools will
access snapshots of the metadata via a metadata snapshot.  I expect to
post the finished code to dm-devel some time in Jan.

More information about what I'm trying to do can be found here:

http://device-mapper.org/blog/2013/11/12/retaining-cache-coherency-with-external-snapshots/


BTW: If you're using dm-thin your backup scenario is trivial.  Just
take a snapshot of the volumes you want to back up.  Take a metadata
snap.  Examine the metadata to see which blocks have changed since you
last backed up.  Copy data.  All you need is already written.

- Joe