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.pav...@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-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/vdo-devel
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
List Archives: 

Reply via email to