LVM snapshot – performance for write-only data

lvmsnapshot

I have a client that is archiving write-only , time-series data in a database (ie. data is rarely modified after it is written, and it is rarely read as it is on a secondary/backup/failover node). I am considering suggesting that the client make periodic LVM snapshots (and eliminating older ones if performance is impacted too much) to allow them to roll back data to a given point in time. Note: I am referring to creating LVM snapshots and using these to allow roll-back on the original data, I am not referring to making an LVM snapshot for copying the data to another filesystem. Given that the data is essentially write-once , the LVM snapshots should be very small (probably close to 0).

My question is, would you expect there be a performance impact on the source volume writes to be caused by the LVM snapshots for this particular kind of data, especially taking into consideration that the copy-on-write will rarely if ever be triggered since existing data is rarely modified? If there is an expected performance impact, does anyone know what level of impact could be expected for this type of a scenario? (remember, this is essentially write-once)

Kind Regards

Best Answer

"normal" LVM snapshots are rather slow for writing - see e.g. https://johnleach.co.uk/words/613/lvm-snapshot-performance. It can drop up to 10%. Making the snapshot ro helps a bit. In yor case thin provisioning should help quite a bit (https://github.com/jthornber/linux-2.6/blob/thin-stable/Documentation/device-mapper/thin-provisioning.txt) - or use btrfs or ZFS, which works in Linux as well.

Related Solutions

Temporary restore LVM snapshot of root

I found a nice and easy solution (uthers solution somehow didn't work for me, I'm not sure why). Rename the lv_root to something like lv_root_old and then rename the snapshot to lv_root.

 $ lvrename /dev/VolGroup/lv_root /dev/VolGroup/lv_root_old
 $ lvrename /dev/VolGroup/snapshot /dev/VolGroup/lv_root

Then add rd_LVM_LV=VolGroup/lv_root_old into the kernel line in grub.conf, so it gets activated (apparently, the snapshot doesn't work if the origin is inactive at boot, since it only contains changes relative to the origin). This is how my grub entry looks like now:

root (hd0,0)
kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto quiet rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_root_old KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM elevator=deadline processor.max_cstate=1
initrd /initramfs-2.6.32-220.el6.x86_64.img

Warning - if you upgraded your kernel between taking the snapshot and now, don't forget to boot the kernel that was used when the snapshot was taken.

LVM Snapshot without copy-on-write

The cost of a snapshot cannot possibly be zero bytes. When a block is changed in the source volume, and you have a snapshot, a copy of the original block prior to modification must be made - the original data must be available somehwere so that it's accessible from the snapshot.

That's what the snapshot size is (plus some metadata): original copies of blocks that have since been changed in the source.

Note that it might be an "accounting trick": an implementation could choose not to overwrite the original block on disk, but rather store the new data somewhere else and update the source block list (or whatever it is it uses to track). In this case the snapshot is "static" as per your definition. But it still causes the overall number of allocated blocks to grow whenever a source block is modified. This space usage should be (an is) accounted against the snapshot.

This is true both for RO and RW snapshots, except that it's a bit more complex in the RW case (you don't want to overwrite a block that was modified in the snapshot by an original block from the source if that is modified too, for example).

Related Question

Difference between fsfreeze and lvm snapshot