LVM thin volume explained

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 8

LVM Thin Volumes to the rescue!

Hey, what are these thin logical volumes? Simply put, they are special volumes which will use only so much spaces as the data they contain need. While they need some more MiB for metadata handling (more about this subject later), that's all.

You can imagine a thin volume as a rubber balloon: it is as large as how much air do you throw at it. And if you want to shrink its, you simply let the air escape.

In a similar fashion, an empty thin volume occupies basically no space apart some megabytes for its metadata. When you create a filesystem on it, the only space occupied is what needed for filesystem structures – and even a multi-TB filesystem need very little space for its structures. It is only when you begin to throw data at your thinly-provided filesystem that the backing thin volume begin to grow, but only as needed for data storage. The upper limit is defined when you create the thin pool.

Shrinking a similar volume is exceedingly simple: you only need to remove some data and then let the filesystem to release the allocated space, via fstrim. This last step is essential: normal file deletion will not trigger the release of any space, with the filesystem only marking the to-be-freed blocks for later reuse. The fstrim command ask the filesystem to explicitly inform the lower-level storage driver (LVM) to release the marked blocks, actually freeing space.

This is, in a nutshell, the principle behind thin volumes. Thin volumes' dynamic nature solve quite a bit of problems:

 if you have many volumes with uncertain storage space, you can simply create a very large thin volume and let actual data to determine its real size – but remember to schedule a fstrim operation, or it will never shrink!

 the same is true for volumes with variable storage requirement: let the data determine how big the volume is, and schedule a (nightly) fstrim operation to recycle some space

 you can over-commit you storage as you want, with a single rule: the maximum size of a thin volume can't be bigger than the container that provide the real space, called thin pool (more on it later)

Ok, the concept is sound. But how it is implemented? In other words, how it works with your precious disks? And, above all, what pros and cons thin volumes do comport?

You have no rights to post comments