search for: max_pwrite_zeros

Am 10.04.2018 um 15:03 hat Nir Soffer geschrieben: > On Tue, Apr 10, 2018 at 1:44 PM Richard W.M. Jones <rjones@redhat.com> > wrote: > > > We now have true zeroing support in oVirt imageio, thanks for that. > > > > However a problem is that ‘qemu-img convert’ issues zero requests for > > the whole disk before starting the transfer. It does this using 32 MB

...s = 32 MB, > > so it's not that efficient after all. I'm not sure if there is a real > > reason for this, but Eric should know. > > > > We support zero with unlimited size without sending any payload to oVirt, > so > there is no reason to limit zero request by max_pwrite_zeros. This limit may > make sense when zero is emulated using pwrite. Yes, this seems wrong, but I'd want Eric to comment. > > > However, since you suggest that we could use "trim" request for these > > > requests, it means that these requests are advisory (since tri...

...so it's not that efficient after all. I'm not sure if there is a real >>> reason for this, but Eric should know. >>> >> >> We support zero with unlimited size without sending any payload to oVirt, >> so >> there is no reason to limit zero request by max_pwrite_zeros. This limit may >> make sense when zero is emulated using pwrite. > > Yes, this seems wrong, but I'd want Eric to comment. The 32M cap is currently the fault of qemu-img, not nbdkit (nbdkit is not further reducing the size of the zero requests it passes on to oVirt); and I explain...

...D block driver has max_pwrite_zeroes = 32 MB, > so it's not that efficient after all. I'm not sure if there is a real > reason for this, but Eric should know. > We support zero with unlimited size without sending any payload to oVirt, so there is no reason to limit zero request by max_pwrite_zeros. This limit may make sense when zero is emulated using pwrite. > > > However, since you suggest that we could use "trim" request for these > > requests, it means that these requests are advisory (since trim is), and > > we can just ignore them if the server does not...

...9;s not that efficient after all. I'm not sure if there is a real > > > reason for this, but Eric should know. > > > > > > > We support zero with unlimited size without sending any payload to oVirt, > > so > > there is no reason to limit zero request by max_pwrite_zeros. This limit > may > > make sense when zero is emulated using pwrite. > > Yes, this seems wrong, but I'd want Eric to comment. > > > > > However, since you suggest that we could use "trim" request for these > > > > requests, it means that these...

...by adding an extension that permits 64-bit lengths, but that's further off in the "nice idea, but not yet documented or implemented" category. > > We support zero with unlimited size without sending any payload to oVirt, > so > there is no reason to limit zero request by max_pwrite_zeros. This limit may > make sense when zero is emulated using pwrite. Even when write zeroes is emulated by falling back to pwrite, the pwrite can be done in a loop (however, then you get into the game of whether writing 2G of zeroes takes long enough that you really DO want to enforce a write zero...

We now have true zeroing support in oVirt imageio, thanks for that. However a problem is that ‘qemu-img convert’ issues zero requests for the whole disk before starting the transfer. It does this using 32 MB requests which take approx. 1 second each to execute on the oVirt side. Two problems therefore: (1) Zeroing the disk can take a long time (eg. 40 GB is approx. 20 minutes).