Re: dm-snapshot scalability - chained delta snapshots approach

["Haripriya S" <sharipriya@novell.com>]

  
>>> Jan Blunck <jblunck@suse.de> 10/24/06 3:22 PM >>> 
On Mon, Oct 23, Molle Bestefich wrote:

> > >Although that includes a complete redesign of the exception store
code.
> > 
> > Especially when you say stuff like that :- ).
> > 

> The chained- snapshots approach needs that too.

 In the chained snapshots, the only addition is a way to tell if an
exception 
 is to be preserved or can be written over. So for every disk-exception
an 
additional field is required (Alasdair also recently suggested that we
could use 
a bitmap to save space). So I would say this is not a major
re-architecture of 
the disk exception structures but a simple (but incompatible) format
change.

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

> Resizing? Nope, you only need to resize the exception store thats it.
Resizing
> the chained- snapshots approach is complex however: in the worst case
you have
> to move the exception stores to get enough free space.

I agree that there is work to be done while resizing. It seems simple
to code 
though and can be done similar to a snapshot delete. If a snapshot is
being 
resized, and will lose exception data, then we need to move the
exception 
and data to the first snapshot after this snapshot in the write chain
which has 
space to hold that data. Yes, data move is involved here. btw I
couldn't figure out 
how resize will work with the common exception store approach. Can you

please explain that in detail ?

Thanks and Regards,
Haripriya