Re: [Qemu-devel] [PATCHv2 07/11] iscsi: let bdrv_create conditionally zero out the device

[Peter Lieven]

Am 02.07.2013 um 11:22 schrieb Paolo Bonzini <address@hidden>:

> Il 01/07/2013 23:36, Peter Lieven ha scritto:
>> 
>> Am 01.07.2013 um 22:20 schrieb Paolo Bonzini <address@hidden>:
>> 
>>> 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.
> 
> Ok, I remember someone reporting timeouts when doing a discard with
> virtio-scsi.  But maybe the problem there was that Linux parallelized
> the requests excessively after splitting them.
> 
>> 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?
> 
> Definitely LVM.  Perhaps in the future gluster too, though right now it
> only supports discard on files, not block devices.

Is discards on LVM sth that is already implemented in qemu?

Would you mind if we postpone the general approach to a later point.
It seems that this is much more complex than the iSCSI approach.
My intention was to fix the iSCSI thin-provisioning problem here.

Peter