Re: dm-snapshot scalability - chained delta snapshots approach

[Jan Blunck <j.blunck@tu-harburg.de>]

On Tue, Sep 26, Haripriya S wrote:

> I had previously put out some performance numbers for origin writes
> where performance goes down drastically w.r.t. the number of snapshots.
> Going further, we identified one of the reasons for the performance drop
> with increase in number of snapshots as the COW copies that happen to
> every snapshot COW device when an origin write happens.

Thanks a lot for your work in this area of the device-mapper. Your performance
numbers show that work is really necessary here.

> We have currently experimented with dm-snapshot code with two different
> approaches and have got good performance numbers. I describe the first
> approach and the results here and appreciate your opinions and inputs on
> this.
> 
> Approach 1 - Chained delta snapshots

This means that every snapshot still has its own exception store. This would
make deletion of snapshots unnecessary complex. It moves the work (copying of
chunks) to the deletion of the snapshot.

We discussed some of the ideas about snapshots here at the dm summit. The
general ideas are as follows:

- one exception store per origin device that is shared by all snapshots
- don't keep the complete exception tables in memory all the time
- limit kcopyd outstanding requests

This would address the two biggest problems that I see with the snapshot
target. The throughput issues should be addressed by only writing to one
exception store. The memory issues should be addressed by the changes to the
exception table handling. Although that includes a complete redesign of the
exception store code.

There are still ongoing discussions about the snapshot target. It would be
nice if you have additional thoughts about this proposal. I guess it is
similar to one of your prototypes.

Jan