Skip to main content
LVM

Thin Provisioning in LVM2

By August 23, 2017September 12th, 2022No Comments

Thin ProvisioningThin Provisioning and Over Provisioning

In my previous blog we looked at LVM Snapshots. Another advanced feature that we can look at in LVM2 is that of Thin Provisioning. This is a feature that is common in most specialist storage hardware and is also part of LVM2, Creating LVM thinly provisioned volumes allow more space to be provisioned than may actually exist on the system. Although this may sound mad it can be beneficial. It is a human trait that we will ask for more than we need. This is true for storage space requirements. So, we may as for 15TB of data but only actually every use 3TB. Using Thin Provisioning in LVM2 will allow for use to deploy volumes with more space than actually exists on the system. This keeps are users happy. We must make sure, though, that we adequately monitor the system to stop that undersupply becoming an issue. In the next lesson we look at Migrating LVM Data

Follow the link below to download the ‘Complete Guide to LVM2 in Linux’, costing just £1.99! Once it is downloaded the eBook can be printed out if required.

Download eBook

Install Required Software

The tools to manage Thin Provisioning in LVM may have to be installed. The package is thin-provisioning-tools in Arch Linux and Ubuntu and in CentOS the package is device-mapper-persistent-data. We can check for the existence of one of the tools, if that is not there we can then install the required package:

Install Ubuntu

# which thin_check || apt-get install -y thin-provisioning-tools

Install Arch

# which thin_check || pacman -S thin-provisioning-tools --no-confirm

Install CentOS

# which thin_check || yum install -y device-mapper-persistent-data

Creating the Thin Pool

LVM Thin Provisioning requires that the thinly provisioned volumes exist in what is known as a Thin Pool. The Thin Pool is just a special type of Logical Volume. The Thin Pool sets how much space is made available to thinly provisioned volumes. It is very important that we monitor the available space in this pool.

# lvcreate -L 200m --thinpool tpool vg1
     Logical volume “tpool” created.

The Thin Pool is created by specifying the –thinpool option when creating the special LV. We have assigned the name tpool and it is being created in the Volume Group vg1. We have set a deliberately small size of 200 MiB so we can demonstrate over provisioning and the need to monitor the Thin Pool. To monitor the Thin Pool tpool we can use lvdisplay.

# lvdisplay /dev/vg1/tpool 
   --- Logical volume ---
   LV Name                tpool
   VG Name                vg1
   LV UUID                0hfHX1-HfFX-bTv0-NmxV-U6fB-c4Qc-Wyh0am
   LV Write Access        read/write
   LV Creation host, time yogi, 2017-08-23 09:49:31 +0000
   LV Pool metadata       tpool_tmeta
   LV Pool data           tpool_tdata
   LV Status              available
   # open                 0
   LV Size                200.00 MiB
   Allocated pool data    0.00%
   Allocated metadata     0.88%
   Current LE             50
   Segments               1
   Allocation             inherit
   Read ahead sectors     auto
   - currently set to     256
   Block device           252:3

Critically, we must monitor the Allocated pool data value. As we have not created any LVs or added data yet this is great with 0% in use. We can also use the command lvs to monitor this value:

# lvs
   LV    VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
   lv1   vg1  -wi-ao---- 600.00m                                                    
   tpool vg1  twi-a-tz-- 200.00m             0.00   0.88

The Data% being the critical column. We can also look at the Attributes in use in the pool:

For tpool the attributes read:

  • Volume Type: Thin pool
  • Permissions: Writable
  • Allocation Policy: Inherited from the Volume Group
  • Fixed minor number is not set
  • State: Is marked as active
  • Device: Is not open or mounted
  • Target type: Is marked as thin provisioning
  • Zeroed: Newly allocated blocks will be overwritten with zeros before use.

Creating Thin Volumes in LVM2

Now that we have the Thin Pool, we can allocate space to Thin Volumes. Remember, that we are limited to a ridiculously small 200 MiB in reality. This does not stop us provisioning more space. This is done on the assumption that the space requested in not likely to equal the space needed. The Urban Penguin Rule of IT users applies:

Space Requested != Space Needed

Even if they do need the requested space it is likely that it will not be needed in totality at the start. More space can be added to the Volume Group and Thin Pool later.

# lvcreate -V 1G --thin -n thin_volume vg1/tpool 
   WARNING: Sum of all thin volume sizes (1.00 GiB) exceeds the size of thin pool vg1/tpool and the size of whole volume group (992.00 MiB)!
   For thin pool auto extension activation/thin_pool_autoextend_threshold should be below 100.
   Logical volume “thin_volume” created.

We can see that a warning is supplied letting us know that we are over provisioning. It also lets us know that we can enable autogrowth of the pool if required. Much in the same way as with snapshots

At least the users are happy, they have their 1 GiB volume not knowing that we have cheated them a little.

If we look at the output of the lvs command again we will see the new volume:

# lvs
   LV          VG   Attr       LSize   Pool  Origin Data%  Meta%  Move Log Cpy%Sync Convert
   lv1         vg1  -wi-ao---- 600.00m                                                     
   thin_volume vg1  Vwi-a-tz--   1.00g tpool        0.00                                   
   tpool       vg1  twi-aotz-- 200.00m              0.00   0.98

We can see that the thin_volume is sized at 1 GiB. The attributes show a little more detail:

For thin_volume the attributes read:

  • Volume Type: Thin Volume
  • Permissions: Writable
  • Allocation Policy: Inherited from the Volume Group
  • Fixed minor number is not set
  • State: Is marked as active
  • Device: Is not open or mounted
  • Target type: Is marked as thin provisioning
  • Zeroed: Newly allocated blocks will be overwritten with zeros before use.

Note: That as the pool in now in use it is marked as open.

Monitoring Pool Usage

The Virtual Size of the thin volume is 1 GiB, as we have mentioned. If we try to format that with the ext4 file system, the process will write enough metadata to support the 1 GiB volume size. As the physical storage is just 200 MiB we will find that the space used jumps significantly with just the formatting of the LV.

# mkfs.ext4 /dev/vg1/thin_volume

Using the lvs command we can see that the file system metadata takes 3% disk space in the thinly volume but 16% of space in the thin pool. It is the thin pool space that we need to take great care over ensuring that it does not run out of space:

# lvs
   LV          VG   Attr       LSize   Pool  Origin Data%  Meta%  Move Log Cpy%Sync Convert
   lv1         vg1  -wi-ao---- 600.00m                                                     
   thin_volume vg1  Vwi-a-tz--   1.00g tpool        3.20                                   
   tpool       vg1  twi-aotz-- 200.00m              16.38  1.37

Configuring Auto Extending of the Thin Pool

Editing the settings in the /etc/lvm/lvm.conf can allow auto growth of the thin pool when required. By default, the threshold is 100% which means that the pool will not grow. If we set this to, 75%, the Thin Pool will autoextend when the pool is 75% full. It will increase by the default percentage of 20% if the value is not changed. We can see these settings using the command grep against the file.

# grep -E ‘^\s*thin_pool_auto’ /etc/lvm/lvm.conf 
 thin_pool_autoextend_threshold = 100
 thin_pool_autoextend_percent = 20

LVM Administration


The video follows