On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven <address@hidden> wrote:
On 19.07.2013 07:58, Paolo Bonzini wrote:
Il 18/07/2013 21:28, Peter Lieven ha scritto:
thanks for the details. I think to have optimal performance and best
change for unmapping in qemu-img convert
it might be best to export the OPTIMAL UNMAP GRANULARITY
Agreed about this.
as well as the write_zeroes_w_discard capability via the BDI
But why this?!? It is _not_ needed. All you need is to change the
default of the "-S" option to be the OPTIMAL UNMAP GRANULARITY if it is
nonzero.
2 reasons:
a) Does this guarantee that the requests are aligned to multiple of the -S
value?
b) If I this flag exists qemu-img convert can do the "zeroing" a priori.
This
has the benefit that combined with bdrv_get_block_status requests before it
might
not need to touch large areas of the volume. Speaking for iSCSI its likely
that
the user sets a fresh volume as the destination, but its not guaranteed.
With the Patch 4 there are only done a few get_block_status requests to
verify
this. If we just write zeroes with BDRV_MAY_UNMAP, we send hundreds or
thousands of writesame requests for possibly already unmapped data.
To give an example. If I take my storage with an 1TB volume. It takes about
10-12
get_block_status requests to verify that it is completely unmapped. After
this
I am safe to set has_zero_init = 1 in qemu-img convert.
If I would convert a 1TB image to this target where lets say 50% are at leat
15MB
zero blocks (15MB is the OUG of my storage) it would take ~35000 write same
requests to achieve the same.
I am not sure I am reading this right, but you dont have to writesame
exactly 1xOUG to get it to unmap.
nxOUG will work too,
So instead of sending one writesame for each OUG range, you can send
one writesame for every ~10G or so.
Say 10G is ~667 OUGs for your case, so you can send
writesame for ~667xOUG in each command and then it would "only" take
~100 writesames instead of ~35000.
So as long as you are sending in multiples of OUG you should be fine.