[Vdo-devel] impact of --emulate512 setting for VDO volumes

[Michael Sclafani]

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 at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/vdo-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vdo-devel/attachments/20190301/7586740c/attachment.htm>