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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/vdo-devel