29.4. Administering VDO
29.4.1. Starting or Stopping VDO
vdo start --name=my_vdo
vdo start --all
vdo start --allcommand at system startup to bring up all activated VDO volumes. See Section 29.4.6, “Automatically Starting VDO Volumes at System Boot” for more information.
vdo stop --name=my_vdo
vdo stop --all
- In synchronous mode, all writes that were acknowledged by VDO prior to the shutdown will be rebuilt.
- In asynchronous mode, all writes that were acknowledged prior to the last acknowledged flush request will be rebuilt.
29.4.2. Selecting VDO Write Modes
- When VDO is in
syncmode, the layers above it assume that a write command writes data to persistent storage. As a result, it is not necessary for the file system or application, for example, to issue FLUSH or Force Unit Access (FUA) requests to cause the data to become persistent at critical points.VDO must be set to
syncmode only when the underlying storage guarantees that data is written to persistent storage when the write command completes. That is, the storage must either have no volatile write cache, or have a write through cache.
- When VDO is in
asyncmode, the data is not guaranteed to be written to persistent storage when a write command is acknowledged. The file system or application must issue FLUSH or FUA requests to ensure data persistence at critical points in each transaction.VDO must be set to
asyncmode if the underlying storage does not guarantee that data is written to persistent storage when the write command completes; that is, when the storage has a volatile write back cache.For information on how to find out if a device uses volatile cache or not, see the section called “Checking for a Volatile Cache”.
automode automatically selects
asyncbased on the characteristics of each device. This is the default option.
--writePolicyoption. This can be specified either when creating a VDO volume as in Section 29.3.3, “Creating a VDO Volume” or when modifying an existing VDO volume with the
vdo changeWritePolicy --writePolicy=sync|async|auto --name=vdo_name
Checking for a Volatile Cache
/sys/block/block_device/device/scsi_disk/identifier/cache_typesysfs file. For example:
sdaindicates that it has a writeback cache:
cat '/sys/block/sda/device/scsi_disk/7:0:0:0/cache_type'write back
sdbindicates that it does not have a writeback cache:
sd 7:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:2:0:0: [sdb] Write cache: disabled, read cache: disabled, supports DPO and FUA
asyncmode for the
syncmode for the
syncwrite policy if the
29.4.3. Removing VDO Volumes
vdo remove --name=my_vdo
vdo removecommand removes the VDO volume and its associated UDS index, as well as logical volumes where they reside.
22.214.171.124. Removing an Unsuccessfully Created Volume
vdoutility is creating a VDO volume, the volume is left in an intermediate state. This might happen when, for example, the system crashes, power fails, or the administrator interrupts a running
vdo remove --force --name=my_vdo
--forceoption is required because the administrator might have caused a conflict by changing the system configuration since the volume was unsuccessfully created. Without the
vdo removecommand fails with the following message:
[...] A previous operation failed. Recovery from the failure either failed or was interrupted. Add '--force' to 'remove' to perform the following cleanup. Steps to clean up VDO my_vdo: umount -f /dev/mapper/my_vdo udevadm settle dmsetup remove my_vdo vdo: ERROR - VDO volume my_vdo previous operation (create) is incomplete
29.4.4. Configuring the UDS Index
--indexMem=sizeoption. The amount of disk space to use will then be determined automatically.
--sparseIndex=enabled --indexMem=0.25options to the
vdo createcommand. This configuration results in a deduplication window of 2.5 TB (meaning it will remember a history of 2.5 TB). For most use cases, a deduplication window of 2.5 TB is appropriate for deduplicating storage pools that are up to 10 TB in size.
29.4.5. Recovering a VDO Volume After an Unclean Shutdown
- If VDO was running on synchronous storage and write policy was set to
sync, then all data written to the volume will be fully recovered.
- If the write policy was
async, then some writes may not be recovered if they were not made durable by sending VDO a
FLUSHcommand, or a write I/O tagged with the
FUAflag (force unit access). This is accomplished from user mode by invoking a data integrity operation like
126.96.36.199. Online Recovery
blocks in useand
blocks free. These statistics will become available once the rebuild is complete.
188.8.131.52. Forcing a Rebuild
operating modeattribute of
vdostatsindicates whether a VDO volume is in read-only mode.)
vdo stop --name=my_vdo
vdo start --name=my_vdo --forceRebuild
29.4.6. Automatically Starting VDO Volumes at System Boot
vdosystemd unit automatically starts all VDO devices that are configured as activated.
- To deactivate a specific volume:
vdo deactivate --name=my_vdo
- To deactivate all volumes:
vdo deactivate --all
- To activate a specific volume:
vdo activate --name=my_vdo
- To activate all volumes:
vdo activate --all
--activate=disabledoption to the
- The lower layer of LVM must be started first (in most systems, starting this layer is configured automatically when the LVM2 package is installed).
vdosystemd unit must then be started.
- Finally, additional scripts must be run in order to start LVM volumes or other services on top of the now running VDO volumes.
29.4.7. Disabling and Re-enabling Deduplication
- To stop deduplication on a VDO volume, use the following command:
vdo disableDeduplication --name=my_vdoThis stops the associated UDS index and informs the VDO volume that deduplication is no longer active.
- To restart deduplication on a VDO volume, use the following command:
vdo enableDeduplication --name=my_vdoThis restarts the associated UDS index and informs the VDO volume that deduplication is active again.
--deduplication=disabledoption to the
29.4.8. Using Compression
184.108.40.206. Enabling and Disabling Compression
--compression=disabledoption to the
- To stop compression on a VDO volume, use the following command:
vdo disableCompression --name=my_vdo
- To start it again, use the following command:
vdo enableCompression --name=my_vdo
29.4.9. Managing Free Space
vdostatsutility; see Section 29.7.2, “vdostats” for details. The default output of this utility lists information for all running VDO volumes in a format similar to the Linux
dfutility. For example:
Device 1K-blocks Used Available Use% /dev/mapper/my_vdo 211812352 105906176 105906176 50%
Reclaiming Space on File Systems
UNMAPcommands. For file systems that do not use
UNMAP, free space may be manually reclaimed by storing a file consisting of binary zeros and then deleting that file.
DISCARDrequests in one of two ways:
- Realtime discard (also online discard or inline discard)
- When realtime discard is enabled, file systems send
REQ_DISCARDrequests to the block layer whenever a user deletes a file and frees space. VDO recieves these requests and returns space to its free pool, assuming the block was not shared.For file systems that support online discard, you can enable it by setting the
discardoption at mount time.
- Batch discard
- Batch discard is a user-initiated operation that causes the file system to notify the block layer (VDO) of any unused blocks. This is accomplished by sending the file system an
FITRIM.You can use the
fstrimutility (for example from
cron) to send this
ioctlto the file system.
discardfeature, see Section 2.4, “Discard Unused Blocks”.
Reclaiming Space Without a File System
blkdiscardcommand can be used in order to free the space previously used by that logical volume. LVM supports the
REQ_DISCARDcommand and will forward the requests to VDO at the appropriate logical block addresses in order to free the space. If other volume managers are being used, they would also need to support
REQ_DISCARD, or equivalently,
UNMAPfor SCSI devices or
TRIMfor ATA devices.
Reclaiming Space on Fibre Channel or Ethernet Network
UNMAPcommand to free space on thinly provisioned storage targets, but the SCSI target framework will need to be configured to advertise support for this command. This is typically done by enabling thin provisioning on these volumes. Support for
UNMAPcan be verified on Linux-based SCSI initiators by running the following command:
sg_vpd --page=0xb0 /dev/device
29.4.10. Increasing Logical Volume Size
vdo growLogicalsubcommand. Once the volume has been grown, the management should inform any devices or file systems on top of the VDO volume of its new size. The volume may be grown as follows:
vdo growLogical --name=my_vdo --vdoLogicalSize=new_logical_size
29.4.11. Increasing Physical Volume Size
- Increase the size of the underlying device.The exact procedure depends on the type of the device. For example, to resize an MBR partition, use the
fdiskutility as described in Section 13.5, “Resizing a Partition with fdisk”.
- Use the
growPhysicaloption to add the new physical storage space to the VDO volume:
vdo growPhysical --name=my_vdo
29.4.12. Automating VDO with Ansible
- Ansible documentation: https://docs.ansible.com/
- VDO Ansible module documentation: https://docs.ansible.com/ansible/latest/modules/vdo_module.html