Chapter 3. Creating a deduplicated and compressed logical volume
You can create an LVM logical volume that uses the VDO feature to deduplicate and compress data.
3.1. LVM-VDO deployment scenarios
You can deploy VDO on LVM (LVM-VDO) in a variety of ways to provide deduplicated storage for:
- block access
- file access
- local storage
- remote storage
Because LVM-VDO exposes its deduplicated storage as a regular logical volume (LV), you can use it with standard file systems, iSCSI and FC target drivers, or as unified storage.
Deploying Ceph Storage on LVM-VDO is currently not supported.
You can deploy LVM-VDO on a KVM server configured with Direct Attached Storage.
You can create file systems on top of a VDO LV and expose them to NFS or CIFS users with the NFS server or Samba.
You can export the entirety of the VDO LV as an iSCSI target to remote iSCSI initiators.
Device Mapper (DM) mechanisms such as DM Crypt are compatible with VDO. Encrypting a VDO LV volumes helps ensure data security, and any file systems above the VDO LV are still deduplicated.
Applying the encryption layer above the VDO LV results in little if any data deduplication. Encryption makes duplicate blocks different before VDO can deduplicate them.
Always place the encryption layer below the VDO LV.
3.2. The physical and logical size of an LVM-VDO volume
This section describes the physical size, available physical size, and logical size that VDO can utilize.
- Physical size
This is the same size as the physical extents allocated to the VDO pool LV. VDO uses this storage for:
- User data, which might be deduplicated and compressed
- VDO metadata, such as the UDS index
- Available physical size
This is the portion of the physical size that VDO is able to use for user data.
It is equivalent to the physical size minus the size of the metadata, minus the remainder after dividing the volume into slabs by the given slab size.
- Logical Size
This is the provisioned size that the VDO LV presents to applications. It is usually larger than the available physical size.
If you do not specify the
--virtualsizeoption, VDO provisions the volume to a
1:1ratio. For example, if you put a VDO LV on top of a 20 GB VDO pool LV, VDO reserves 2.5 GB for the UDS index, if the default index size is used. The remaining 17.5 GB is provided for the VDO metadata and user data. As a result, the available storage to consume is not more than 17.5 GB, and can be less due to metadata that makes up the actual VDO volume.
VDO currently supports any logical size up to 254 times the size of the physical volume with an absolute maximum logical size of 4 PB.
- For more information on how much storage VDO metadata requires on different physical sizes, see Section 2.3, “Examples of VDO requirements by physical size”.
3.3. The recommended logical size for VDO logical volumes
When you set up a VDO logical volume (LV), you specify the amount of logical storage that the VDO LV presents. Red Hat recommends the following logical sizes for these use cases:
- When hosting active VMs or containers, Red Hat recommends provisioning storage at a 10:1 logical to physical ratio: that is, if you are utilizing 1 TB of physical storage, you would present it as 10 TB of logical storage.
- For object storage, such as the type provided by Ceph, Red Hat recommends using a 3:1 logical to physical ratio: that is, 1 TB of physical storage would present as 3 TB logical storage.
In either case, you can simply put a file system on top of the VDO LV and then use it directly or as part of a distributed cloud storage architecture.
3.4. Slab size in VDO
The physical storage of the VDO volume is divided into a number of slabs. Each slab is a contiguous region of the physical space. All of the slabs for a given volume have the same size, which can be any power of 2 multiple of 128 MB up to 32 GB.
The default slab size is 2 GB in order to facilitate evaluating VDO on smaller test systems. A single VDO volume can have up to 8192 slabs. Therefore, in the default configuration with 2 GB slabs, the maximum allowed physical storage is 16 TB. When using 32 GB slabs, the maximum allowed physical storage is 256 TB. VDO always reserves at least one entire slab for metadata, and therefore, the reserved slab cannot be used for storing user data.
Slab size has no effect on the performance of the VDO volume.
Table 3.1. Recommended VDO slab sizes by physical volume size
|Physical volume size||Recommended slab size|
100 GB – 1 TB
You can control the slab size by providing the
--vdoSlabSize=megabytes option to the
vdo create command.
3.5. Installing VDO
This procedure installs software necessary to create, mount, and manage VDO volumes.
# yum install vdo kmod-kvdo
3.6. Creating an LVM-VDO volume
This procedure creates an VDO logical volume (LV) on a VDO pool LV.
- Install the VDO software. See Section 3.5, “Installing VDO”.
- An LVM volume group with free storage capacity exists on your system.
Pick a name for your VDO LV, such as
vdo1. You must use a different name and device for each VDO LV on the system.
In all the following steps, replace vdo-name with the name.
Create the VDO LV:
# lvcreate --type vdo \ --name vdo-name --size physical-size --virtualsize logical-size \ vg-name
- Replace vg-name with the name of an existing LVM volume group where you want to place the VDO LV.
- Replace logical-size with the amount of logical storage that the VDO LV will present.
If the physical size is larger than 16TiB, add the following option to increase the slab size on the volume to 32GiB:
If you use the default slab size of 2GiB on a physical size larger than 16TiB, the
lvcreatecommand fails with the following error:
ERROR - vdoformat: formatVDO failed on '/dev/device': VDO Status: Exceeds maximum number of slabs supported
Example 3.1. Creating a VDO LV for container storage
For example, to create a VDO LV for container storage on a 1TB VDO pool LV, you can use:
# lvcreate --type vdo \ --name vdo1 --size 1T --virtualsize 10T \ vg-nameImportant
If a failure occurs when creating the VDO volume, remove the volume to clean up.
Create a file system on the VDO LV:
For the XFS file system:
# mkfs.xfs -K /dev/vg-name/vdo-name
For the ext4 file system:
# mkfs.ext4 -E nodiscard /dev/vg-name/vdo-name
3.7. Mounting an LVM-VDO volume
This procedure mounts a file system on an LVM-VDO volume, either manually or persistently.
- An LVM-VDO volume exists on your system. For more information, see Section 3.6, “Creating an LVM-VDO volume”.
To mount the file system on the LVM-VDO volume manually, use:
# mount /dev/vg/vdo-name mount-point
To configure the file system to mount automatically at boot, add a line to the
For the XFS file system:
/dev/vg/vdo-name mount-point xfs defaults,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0
For the ext4 file system:
/dev/vg/vdo-name mount-point ext4 defaults,x-systemd.device-timeout=0,x-systemd.requires=vdo.service 0 0
If the LVM-VDO volume is located on a block device that requires network, such as iSCSI, add the
For iSCSI and other block devices requiring network, see the
systemd.mount(5)man page for information on the
3.8. Changing the compression and deduplication settings on an LVM-VDO volume
This procedure enables or disables the compression and deduplication of a VDO pool logical volume (LV).
Compression and deduplication are enabled by default.
- An LVM-VDO volume exists on your system.
To find out if the compression and deduplication is enabled or disabled on your logical volumes:
# lvs -o+vdo_compression,vdo_deduplication
Find out status of the compression and status of the deduplication index of your running active VDOPoolLV:
# lvs -o+vdo_compression_state,vdo_index_state
vdo_index_statecan show as
To enable or disable the compression for VDOPoolLV:
# lvchange --compression y|n vgname/vdopoolname
To enable or disable the deduplication for VDOPoolLV:
# lvchange --deduplication y|n vgname/vdopoolname
For more information, see