Am 01.07.2013 um 22:20 schrieb Paolo Bonzini <pbonz...@redhat.com>: > Il 27/06/2013 15:11, Peter Lieven ha scritto: >> if the device supports unmapping and unmapped blocks read as >> zero ensure that the whole device is unmapped and report >> .has_zero_init = 1 in this case to speed up qemu-img convert. > > This can still take several minutes. Do you need any special timeout in > libiscsi?
Not as far as I know. The number of unmapped sectors is bound by iscsilun->max_unmap. This is what the storage will handle in one request. For my storage its the internal page size (15MB). Its very fast. Except for some broken storages I expect that unmapping on a thin-provisioned target means deleting of pointers or something similar not actually writing something to the disks. This it what the SANITIZE command does. Do you have evidence that it is really taking minutes somewhere? I tested it with a fully allocated 1TB volume. In my case it was a question of about 20 seconds. I think this was mainly due to the thousands of sync requests that had to be sent. > > Perhaps we can have a new "discard_zeroes" field in bdrv_get_info, and > the unmap functionality can be moved up to qemu-img convert? Is there any other storage protocol out there that could benefit from it? Peter
