search for: xtremio

...after the highest write offset, since the > plugin > created a new image, and we know that the image is empty. > > When the destination is a block device we cannot avoid zeroing since a block > device may contain junk data (we usually get dirty empty images from our > local > xtremio server). (Off topic for qemu-block but ...) We don't have enough information at our end to know about any of this. > > The problem is that the NBD 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 > &g...

...created a new image, and we know that the image is empty. > > > > > > When the destination is a block device we cannot avoid zeroing since a > > block > > > device may contain junk data (we usually get dirty empty images from our > > > local > > > xtremio server). > > > > (Off topic for qemu-block but ...) We don't have enough information > > at our end to know about any of this. > > > > Can't use use this logic in the oVirt plugin? > > file based storage -> skip initial zeroing > block based stor...

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

On 04/10/2018 09:40 AM, Richard W.M. Jones wrote: >> When the destination is a block device we cannot avoid zeroing since a block >> device may contain junk data (we usually get dirty empty images from our >> local >> xtremio server). > > (Off topic for qemu-block but ...) We don't have enough information > at our end to know about any of this. Yep, see my other email about a possible NBD protocol extension to actually let the client learn up-front if the exported device is known to start in an all-zero...

...image, you can ignore zero requests after the highest write offset, since the plugin created a new image, and we know that the image is empty. When the destination is a block device we cannot avoid zeroing since a block device may contain junk data (we usually get dirty empty images from our local xtremio server). > The problem is that the NBD 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 t...

...he image is empty. > > > > > > > > When the destination is a block device we cannot avoid zeroing since > a > > > block > > > > device may contain junk data (we usually get dirty empty images from > our > > > > local > > > > xtremio server). > > > > > > (Off topic for qemu-block but ...) We don't have enough information > > > at our end to know about any of this. > > > > > > > Can't use use this logic in the oVirt plugin? > > > > file based storage -> skip...

...the > > plugin > > created a new image, and we know that the image is empty. > > > > When the destination is a block device we cannot avoid zeroing since a > block > > device may contain junk data (we usually get dirty empty images from our > > local > > xtremio server). > > (Off topic for qemu-block but ...) We don't have enough information > at our end to know about any of this. > Can't use use this logic in the oVirt plugin? file based storage -> skip initial zeroing block based storage -> use initial zeroing Do you think t...

...k device, try ioctl(BLKZEROOUT) - Otherwise fallback to manual zeroing The handle keeps now the underlying file capabilities, so once we discover that an operation is not supported, we never try it again. Here are examples runs on a server based on Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz, using XtremIO storage via 4G FC HBA and 4 paths to storage. $ export SOCK=/tmp/nbd.sock $ export BLOCK=/dev/e30bfac2-8e13-479d-8cd6-c6da5e306c4e/c9864222-bc52-4359-80d7-76e47d619b15 $ src/nbdkit -f plugins/file/.libs/nbdkit-file-plugin.so file=$BLOCK -U $SOCK $ time qemu-img convert -n -f raw -O raw /var/tmp/...

...return rather than doing the 'highestwrite' check unconditionally even when oVirt supports zero requests? > > When the destination is a block device we cannot avoid zeroing since a block > device may contain junk data (we usually get dirty empty images from our > local > xtremio server). And that's why qemu-img is starting life with write zeroes requests - because it needs to guarantee that the image either already started as all zeroes, or that zeroes are written to overwrite junk data. >> The problem is that the NBD block driver has max_pwrite_zeroes = 32 MB,...

This is the second version to support efficient zero for block devices on older kernels (e.g. RHEL 7.5), and file systems that do not support yet FALLOC_FS_ZERO_RANGE (e.g. NFS 4.2). Changes since v1: - Split to smaller patches - Skip linux only includes on other systems - Skip code using BLKZEROOUT if the macro is not defined - Try BLKZEROOUT only if the offset and count are aligned to device

...k device, try ioctl(BLKZEROOUT) - Otherwise fallback to manual zeroing The handle keeps now the underlying file capabilities, so once we discover that an operation is not supported, we never try it again. Here are examples runs on a server based on Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz, using XtremIO storage via 4G FC HBA and 4 paths to storage. $ export SOCK=/tmp/nbd.sock $ export BLOCK=/dev/e30bfac2-8e13-479d-8cd6-c6da5e306c4e/c9864222-bc52-4359-80d7-76e47d619b15 $ src/nbdkit -f plugins/file/.libs/nbdkit-file-plugin.so file=$BLOCK -U $SOCK $ time qemu-img convert -n -f raw -O raw /var/tmp/...