[dm-devel] dm-snapshot scalability - chained delta snapshots approach

[Molle Bestefich]

Haripriya S wrote:
> Approach 1 - Chained delta snapshots
>
> Advantages:
> 1. Very simple, adds very few lines of code to existing dm-snap code.

Nice.

> 2. Does not change the dm-snapshot architecture, and no changes
> required in LVM or EVMS

Nice.

> 3. Since the COW copies due to origin write will always go to the most
> recent snapshot, snapshot COW devices can be created with less size.
> Whenever the COW allocation increase beyond say 90%, a new snapshot can
> be created which will take all the subsequent COW copies. This may avoid
> making COW devices invalid.

Nice !!!!!

> Disadvantages:
> 1. snapshots which were independent previously are now dependent on
> each other. Corruption of one COW device will affect the other snapshots
> as well.

Fixing dm-snapshot so devices do not get corrupted would make
dm-snapshot immensely more useful.
One way of doing that is to provoke bugs to more quickly become
visible to the user.  I think your patch might accomplish this.
Another way is to keep the code simple.  I'd say your patch does that.

(A third way is extensive testing, and a fourth is mathematically
proving that the code is sane.  But who has the time and energy ;-).)

Overall, what you're doing looks like a good thing for stability.

> 2. Will have a small impact in snapshot read performance,
> currently (if I understood right)

Minor disadvantage compared to the massive improvements seen in write speed.
Can be optimized on later.

(Fx. caching a list of which exceptions exist other places in the chain..)

> 3. There is a need to change the disk exception structure

Hopefully there's a version number on disk which allows incompatible
tools to skip lv's or whatever.

If not, this is a great excuse to create one.

> 4. When snapshots are deleted the COW exceptions have to be transferred
> to the next snapshot in the write chain.

Jan Blunck wrote:
> This means that every snapshot still has its own exception store.
> This would make deletion of snapshots unnecessary complex.

Complex, how?

Necessary operations (in order listed):
 * Acquire exclusive lock on this snapshot.
 * Check that next snapshot has room for exceptions, abort if not.
 * Acquire exclusive lock on next snapshot.
 * Move all exceptions to next snapshot.
 * Unlock next snapshot.
 * Remove this snapshot.
 * Done...

Sounds simple to me, but maybe I'm missing the point.

> It moves the work (copying of chunks)
> to the deletion of the snapshot.

Snapshot deletion is usually a "low privilege" task, something done
to redeem disk space on a periodic schedule.  It is not something a
user absolutely needs to finish immediately.  Sounds like a very
fair deal to me, but then again, I'm just a user.

> 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

Now that sounds complex.

> Although that includes a complete redesign of the exception store code.

Especially when you say stuff like that :-).

> The throughput issues should be addressed by only
> writing to one exception store.

Wouldn't this make debugging more complex, and further add to
the difficulty of snapshot resizing?