[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] A snapshot is not (really) a cow

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. However I have sucessfully followed the following recipe (essentially as suggested in this list) for creating lvm2 things which can be used as copy-on-write file systems for xenU domains:

# create a volume group
vgcreate vmgroup /dev/xxx /dev/yyy

# create a logical volume for a common root filesystem
lvcreate -L6G -n root_file_system vmgroup
mkfs -t ext3 /dev/vmgroup/root_file_system

# initialise the root_file_system - eg copy an existing install
mount /dev/vmgroup/root_file_system /mnt/new_root/
mount [partition containing pristine root fs] /dev/pristine_root
cp -ax /mnt/pristine_root/* /mnt/new_root

# create lvm2 'snapshots' allowing (eg) 512M of modification each
lvcreate -L512M -s -n u1 /dev/vmgroup/root_file_system
lvcreate -L512M -s -n u2 /dev/vmgroup/root_file_system
lvcreate -L512M -s -n u3 /dev/vmgroup/root_file_system

# now we have 3 lvm2 things to use as COW file systems for xenU domains
black-magic-to-configure-and-start-a-domain u1
black-magic-to-configure-and-start-a-domain u2
black-magic-to-configure-and-start-a-domain u3

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

# no other way of recovering that I know of

After the reboot, it seems that the new 'snapshot' u4 was created, and is in fact usable.

The nasty messages mention running out of memory, and complain that the previously created 'snapshot' (/dev/vmgroup/u3) is not available.

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

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.

Have I missed something?

In the worst case, this means defining a new kind of logical volume with its own driver, and modifying the user space tools to deal with it. Alternatively it may be possible to tweak only the lvm2 userspace tools.

Or has Bin Ren's 2.4 series code been reconstituted for lvm2 and 2.6?

There was also mention of a cow file handler tweak to the kernel root-nfs handler - did anything come of that?

In user-mode-linux and qemu, cow file handling is incorporated into the emulator-system interface. Is there any scope for doing something like that in xen0?

I haven't yet looked at migration (partly because I don't know where to find information about it). Does the choice of root file system technology interact with migration? If so, is this an argument for pushing cow stuff into the system so as to ensure the cows can migrate?

Incidentally I now get a string of messages about nbdNNN during a reboot/shutdown - I didn't get a chance to note them precisely. Is that nbd as in network block device?

This message has got rather long. Thanks anyway.

This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.