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&gt; 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 >