search

dm-vdo / vdo

Userspace tools for managing VDO volumes.
GNU General Public License v2.0
193 stars 32 forks source link

question about unsupported configuration #26

Closed kjy8901 closed 4 years ago

kjy8901 commented 4 years ago

hello

Can I ask why you don't support this configuration?

If you don't mind, it would be great to explain why you don't support each one.

The following configurations are not supported:

link : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-qs-requirements

Thank you

rhawalsh commented 4 years ago

HI @kjy8901,

The following configurations are not supported:

  • VDO on top of VDO volumes: storage → VDO → LVM → VDO

There are a few issues at play in this configuration. This is primarily directed at having VDO volumes stacked on top of VDO volumes within the same kernel since you can't reasonably detect whether VDO is stacked when you're presenting it across something like an iSCSI lun, for example.

  1. There is a threading issue that we have come across in the past that we think is related (BZ1537795).
  2. VDO does not send discards to the storage below, so space usage reporting will be inaccurate on the lowest-in-the-stack VDO.
  3. Since you'll already be deduplicating the data, you won't actually see any benefits from the storage efficiency, either.
  • VDO on top of LVM Snapshots

This is not tested.

  • VDO on top of LVM Cache

This is not tested.

  • VDO on top of the loopback device

This is not tested.

  • VDO on top of LVM Thin Provisioning

VDO does not send discards to the storage below, and the usage of the block device underneath will end up being 100% used over time because of the way VDO lays the data out. There is no benefit to putting VDO on top of a thinly provisioned device.

  • Encrypted volumes on top of VDO: storage → VDO → DM-Crypt

Similar to putting VDO on top of a thinly provisioned device. If you write encrypted data on top of VDO, you will not see any space savings benefits, so there is no point in doing this. Therefore we do not support it.

  • Partitions on a VDO volume: fdisk, parted, and similar partitions

This could result in unaligned blocks which would significantly affect any space savings you might be able to realize.

  • RAID (LVM, MD, or any other type) on top of a VDO volume

This could result in unaligned blocks which would significantly affect any space savings you might be able to realize.