[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk
From: |
Richard W.M. Jones |
Subject: |
Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk |
Date: |
Tue, 10 Apr 2018 15:40:38 +0100 |
User-agent: |
Mutt/1.5.20 (2009-12-10) |
On Tue, Apr 10, 2018 at 02:07:33PM +0000, Nir Soffer wrote:
> This makes sense if the device is backed by a block device on oVirt side,
> and the NBD support efficient zeroing. But in this case the device is backed
> by an empty sparse file on NFS, and oVirt does not support yet efficient
> zeroing, we just write zeros manually.
>
> I think should be handled on virt-v2v plugin side. When zeroing a file raw
> 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).
(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
> > 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 trim is), and
> > > we can just ignore them if the server does not support trim.
> >
> > What qemu-img sends shouldn't be a NBD_CMD_TRIM request (which is indeed
> > advisory), but a NBD_CMD_WRITE_ZEROES request. qemu-img relies on the
> > image actually being zeroed after this.
> >
>
> So it seems that may_trim=1 is wrong, since trim cannot replace zero.
Note that the current plugin ignores may_trim. It is not used at all,
so it's not relevant to this problem.
However this flag actually corresponds to the inverse of
NBD_CMD_FLAG_NO_HOLE which is defined by the NBD spec as:
bit 1, NBD_CMD_FLAG_NO_HOLE; valid during
NBD_CMD_WRITE_ZEROES. SHOULD be set to 1 if the client wants to
ensure that the server does not create a hole. The client MAY send
NBD_CMD_FLAG_NO_HOLE even if NBD_FLAG_SEND_TRIM was not set in the
transmission flags field. The server MUST support the use of this
flag if it advertises NBD_FLAG_SEND_WRITE_ZEROES. *
qemu-img convert uses NBD_CMD_WRITE_ZEROES and does NOT set this flag
(hence in the plugin we see may_trim=1), and I believe that qemu-img
is correct because it doesn't want to force preallocation.
Rich.
* https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Nir Soffer, 2018/04/10
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Kevin Wolf, 2018/04/10
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Nir Soffer, 2018/04/10
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Nir Soffer, 2018/04/10
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Richard W.M. Jones, 2018/04/10
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Nir Soffer, 2018/04/11
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Nir Soffer, 2018/04/12
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Richard W.M. Jones, 2018/04/12
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Eric Blake, 2018/04/12
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Nir Soffer, 2018/04/12
- Re: [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk, Richard W.M. Jones, 2018/04/12