On Fri, Jul 19, 2013 at 6:49 AM, Peter Lieven <p...@kamp.de> wrote: > On 19.07.2013 15:25, ronnie sahlberg wrote: >> >> On Thu, Jul 18, 2013 at 11:08 PM, Peter Lieven <p...@kamp.de> 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. > > do I not have to take care of max_ws_size?
Yes you need to handle mas_ws_size but I would imagine that on most targets that max_ws_size >> OUG I would be surprised if a target would set max_ws_size to just a single OUG. > > Peter