› Xen Copy-On-Write Notes

LVM Disk Snapshots

• Xen and LVM
• LVM2

From xen-devel:

Snapshots work with LVM2 on Linux 2.4, assuming all the device mapper patches are applied to the kernel. Say we start with a logical volume /dev/vg1/disk, then create an LVM snapshot of vg1/disk called vg1/disk-snap. We could mount vg1/disk-snap as a read-only filesystem to store a consistent backup of vg1/disk; this is the normal suggested use. But LVM actually makes both resulting devices writable, so we could equally well not touch vg1/disk and use vg1/disk-snap as a writable, CoW block device. (If we did accidentally touch vg1/disk, LVM would keep those changes isolated from the snapshots.) While LVM won't allow snapshots of snapshots, multiple snapshots of the same underlying (non-snapshot) device are allowed. So we could start with vg1/disk and create vg1/disk-copy1, vg1/disk-copy2, vg1/disk-copy3, and so on, as CoW devices.

UnionFS

• Provides COW for existing directories in a filesystem, i.e. works at the filesystem level, not block device
• You mount a new COW directory that combines a number of defined directories
• Example from Ndiyo

From flaviostechnotalk.com:

Let's suppose that you want to have versioning capabilities on the /var/original/ directory tree. In order to create the base unionfs, first of all, you would need to load the unionfs module:

modprobe unionfs

Then create the unionfs and mount it under /var/base/ (from now on, you will need to access /var/original/ always through /var/base/). So let's create the new directory:

mkdir /var/base

And let's mount the unionfs on top of it:

mount -t unionfs -o rw,dirs=/var/original=rw null /var/base/

In plain english, the above command would mount /var/base as read-write on /var/base/, and the whole unionfs would be read-write. At this point you can start using /var/base/ the same way you used /var/original/ before. As soon as you decide to take an snapshot and freeze the original directory, you would create a new directory (where new changes will be stored):

mkdir /var/snap01

Then you would add this new directory to the fan structure of your /var/base unionfs, and make /var/original read-only for that unionfs: unionctl /var/base-add-mode rw /var/snap01 unionctl /var/base-mode ro /var/original Make sure that you execute the above commands in this sequence, otherwise your /var/base will become read-only momentarily (as it won't have any read-write branch to commit changes to, until you add the /var/snap01 branch to it).

At this point /var/original will remain the same for ever. Any modifications that you perform to /var/base will be stored under /var/snap01. You can back up /var/original to a read-only media or to tape. Rolling back all changes to the original status would be as simple as doing this:

unionctl /var/base --remove /var/snap01

/var/original will still remain read-only. Now let’s assume that you decide to create a new snapshot. So you would create a new directory:

mkdir /var/snap02

Add it to the /var/base view as the new read-write branch, making the previous branch read-only:

unionctl /var/base --add --mode rw /var/snap02 unionctl /var/base --mode ro /var/snap01

From now on, all new changes will be stored in /var/snap02, so /var/snap01 will remain unmodified (to be stored in read-only media if you want). If you list the fan of /var/base, you would see:

unionctl /var/base --list /var/snap02 (rw) /var/snap01 (r_) /var/original (r_)

You can repeat the same process, over and over, creating and adding branches to the fan structure every time you need a consistent roll-back point.