LVM thin volume explained

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 8
PoorBest 

Snapshot: normal volumes vs thin volumes

One of the key advantage LVM has over normal partition scheme is its filesystem-independent snapshot support. Let first see how snapshots work in normal logical volumes:

In short, any write to the original volume is paused and the to-be-overwritten data are copied in a backup volume; after the copy, the original write is released and proceeds as normal. When reading from a snapshot, unwritten data are read from the original volume, while the previous state of overwritten data is retrieved from the backup copy in the snapshot volume. The block's changed/not-changed status is stored inside a small metadata structure attached to the snapshot.

This give a consistent, point in a time view of the underlying block device. However, as any new write to the original volume trigger a block copy from one volume to another, the entire process is quite slow. With the added snapshot-related metadata handling, it is not uncommon to get a 5-10X (or more) slowdown.

This is even worse when taking multiple snapshots of the same original volume: data need to be copied for any snapshot volume, killing performance (complexity: O(n))

Also note that snapshot size is a creation-time parameter: if you undersize your snapshot, it will be dropped when full. If you too much oversize it, you will be wasting your space. As a side note, this difficulty in snapshot size management is one of the key reason behind LVM monitor daemon – which can auto-resize normal snapshots when they are almost full.

On the other hand, when a snapshot is removed, you don't have to merge anything: new writes are already “in-place” inside the original volume. This also mean that the original volume remains a compact object, not being fragmented or scattered over the entire disk surface.

Now enter the thin snapshot arena:

Thin snapshots and volumes are all about metadata. When snapshotting a volume, its metadata are copied for use by the thin snapshot volume. So, while new writes change volume's own metadata, the snapshot volume (with its original metadata copy) continue to address the original data. In other words, new writes have a reduced performance degradation. More importantly, multiple snapshots of the same original volume are as fast as volumes with single snapshots (complexity: O(1)). Even snapshot chains (snapshot of snapshot of snapshot of...) can be efficiently managed.

The disadvantage is a very scattered disk layout: while normal thin volumes can become quite fragmented, snapshotted thin volumes can be even more so.

Also note that what depicted above is a somewhat best-case scenario: when the incoming write is smaller than the pool chunk size (range: 64 KiB – 1.0 GiB) even a thin snapshot need to copy the original data to preserve later availability. Anyway, thin snapshots generally remain faster than normal LVM snapshots, especially in the multiple-snaphosts-for-volume case.

You have no rights to post comments