Re: [Xen-devel] A snapshot is not (really) a cow - Christian Limpach - com.xensource.lists.xen-devel

12 messages in com.xensource.lists.xen-develRe: [Xen-devel] A snapshot is not (re...

From	Sent On	Attachments
Peri Hankey	26 Sep 2004 04:37
Christian Limpach	26 Sep 2004 07:48
Peri Hankey	26 Sep 2004 12:05
Ian Pratt	26 Sep 2004 12:27
Peri Hankey	26 Sep 2004 14:28	.gz
Ian Pratt	26 Sep 2004 14:44
Peri Hankey	27 Sep 2004 00:57
Peri Hankey	27 Sep 2004 01:40
Ian Pratt	27 Sep 2004 03:12
Peri Hankey	27 Sep 2004 04:29
Peri Hankey	27 Sep 2004 06:35
Christian Limpach	27 Sep 2004 10:21

Subject:	Re: [Xen-devel] A snapshot is not (really) a cow
From:	Christian Limpach (Chri...@cl.cam.ac.uk)
Date:	09/26/2004 07:48:20 AM
List:	com.xensource.lists.xen-devel

On Sun, Sep 26, 2004 at 12:38:06PM +0100, Peri Hankey wrote:

I always found the lvm2 'snapshot' terminology confusing - the thing created as a 'snapshot' is what accepts changes while a backup is made of the original volume.

I don't think that's the terminology the LVM2 people use. The regular use is to create a snapshot and backup this snapshot while you keep using the original.

# drat - I needed another domain lvcreate -L512M -s -n u4 /dev/vmgroup/root_file_system ... nasty messages .... all xenU domains dead .... ... lmv2 system in inconsistent state ... ... /dev/vmgroup/u4 doesn't exist ... ... /dev/mapper/root_file_system-u4 does exist ...

This should work, if it doesn't then it would seem to be a bug in LVM2. Since you mention out of memory error messages, are you sure that you're not running out of memory in dom0?

The problem is that the 'snapshot' cows hold onto each other's tails - they seem to be held in a list linked (I think) from the original logical volume (here /dev/vmgroup/root_file_system). For their intended use as enabling backup, this seems to be meant to allow writes to the original volume to be propagated to all 'snapshots' created against that volume - there are comments about getting rid of the 'snapshots' after the backup has been done because this propagation of writes hits performance.

For my requirements, and I imagine for most others reading this list, all of this is superfluous. I don't need

original -> snap1 -> snap2 -> snap3 ...

This is not the layout LVM2 uses. If you look at the output of ``dmsetup table'', you'll see that each snapshot is independent and only refers to the device it is a snapshot of and to its cow device which will hold modifications.

so that I can't create a new snap4 while any of the others are in use.

I just need

original <- cow1 original <- cow2 original <- cow3 original <- cow4 ...

where A '<-' B means B is a cow image of A, and where each of the cows is independent of the others so that a new cow can be created at any time, regardless how many others are active.

This is the layout LVM2 uses. And it is indeed simple (and should be quite robust) as long as you don't want to write to the original. If you write to the original, you will have to copy the changed blocks to every snapshot's cow device. I think I've seen this fail when having multiple snapshots and writing to the original. But since you didn't write to the original (and one generally doesn't need/want to write to the original in our case), that problem is unlikely to be relevant to the failure you've seen.

christian