Hi!

512 emulation was intended to support drivers that only do a fraction of their I/O in blocks smaller 4KB. It is not optimized for performance in any way. Under the covers, VDO is still operating on 4KB physical blocks, so each 512-byte read is potentially amplified to a 4KB read, and each 512-byte write to a 4KB read followed by a 4KB write. A workload consisting exclusively of 512-byte randomly-distributed writes could effectively be amplified by a factor of 16.

We have a suite of automated tests we run in 512e mode on a nightly basis. That suite is a subset of our regular tests, containing only ones we expect would be likely to expose problems specific to the emulation.

There should be no penalty to having emulation enabled on a volume that no longer uses it. If the I/O is 4KB-aligned and 4KB or larger, having it enabled won't affect it.

It does not appear the setting can be modified by the VDO manager, but I cannot remember at this moment why that should be so.

Hope this helps.

On Fri, Mar 1, 2019 at 2:24 PM Guillaume Pavese <guillaume.pavese@interactiv-group.com> wrote:

Hello,

We are planning to deploy VDO with oVirt 4.3 on centos 7.6 (on SSD devices).

As oVirt does not support 4K devices yet, VDO volumes are created with the parameter "--emulate512 enabled"

What are the implications of this setting? Does it impact performance? If so, is it IOPS or throughput that is impacted? What about reliability (is that mode equally tested as standard mode)?

As I saw on RH Bugzilla, support for 4K devices in oVirt will need to wait at least for Centos 7.7

Once that is supported, would it be possible to transition/upgrade an emulate512 vdo volume to a standard one?

Thanks,

Guillaume Pavese
Ingénieur Système et Réseau

Interactiv-Group

_______________________________________________
Vdo-devel mailing list
Vdo-devel@redhat.com
https://www.redhat.com/mailman/listinfo/vdo-devel