Re: dm-snapshot scalability - chained delta snapshots approach

[rgammans@computer-surgery.co.uk]

[-- Attachment #1.1: Type: text/plain, Size: 1915 bytes --]

On Wed, Sep 27, 2006 at 11:17:00AM +0200, Jan Blunck wrote:
> 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
[snip]
> 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

I have a need fro a 'snapshot' type dm mode which has this
characterstic. Eg, it leavse to origin device completely untouch by any
changes. 

I was thinking that I'd have to code it myself from scratch as I could
see any simple way of reuse the existing dm-snap code - especially since
in my case the origin device will always be a physical volume (ie hda).

However if I can make use of a new dm-exception-store and possibly
even contribute to it this would be better.

I was considering some sort of B or B+ -tree type arrangement as then
we can use the buffer-cache (I'm assuming something similiar still
exists after the bh -> bio rewrite but I 'm a lttle behind) to store
the commonly referenced exceptions, which should keep the memory
required by the tables down at times of high memory pressure.

> 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.

Is this where those discussion are taking place if I want to help 
and particpate?

TTFN
-- 
Roger. 	                        Home| http://www.sandman.uklinux.net/
Master of Peng Shui.      (Ancient oriental art of Penguin Arranging)
Work|Independent Sys Consultant | http://www.computer-surgery.co.uk/
 New key Fpr: 1227 ABB1 7545 77A7 6816  2D18 4EBC AA9B 8EE3 1DD3

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]