Re: [Qemu-devel] write_zeroes/trim on the whole disk

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

On 24.09.2016 20:13, Vladimir Sementsov-Ogievskiy wrote:
> On 24.09.2016 19:49, Alex Bligh wrote:
>>> On 24 Sep 2016, at 17:42, Vladimir Sementsov-Ogievskiy 
>>> <vsementsov@virtuozzo.com> wrote:
>>>
>>> On 24.09.2016 19:31, Alex Bligh wrote:
>>>>> On 24 Sep 2016, at 13:06, Vladimir Sementsov-Ogievskiy 
>>>>> <vsementsov@virtuozzo.com> wrote:
>>>>>
>>>>> Note: if disk size is not aligned to X we will have to send 
>>>>> request larger than the disk size to clear the whole disk.
>>>> If you look at the block size extension, the size of the disk must 
>>>> be an exact multiple of the minimum block size. So that would work.
>
> This means that this extension could not be used with any qcow2 disk, 
> as qcow2 may have size not aligned to its cluster size.
>
> # qemu-img create -f qcow2 mega 1K
> Formatting 'mega', fmt=qcow2 size=1024 encryption=off 
> cluster_size=65536 lazy_refcounts=off refcount_bits=16
> # qemu-img info mega
> image: mega
> file format: qcow2
> virtual size: 1.0K (1024 bytes)
> disk size: 196K
> cluster_size: 65536
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>     refcount bits: 16
>     corrupt: false
>
> And there is no such restriction in documentation. Or we have to 
> consider sector-size (512b) as block size for qcow2, which is too 
> small for our needs.
>
>>>>
>>> But there is no guarantee that disk_size/block_size < INT_MAX..
>> I think you mean 2^32-1, but yes there is no guarantee of that. In 
>> that case you would need to break the call up into multiple calls.
>>
>> However, being able to break the call up into multiple calls seems 
>> pretty sensible given that NBD_CMD_WRITE_ZEROES may take a large 
>> amount of
>> time, and a REALLY long time if the server doesn't support trim.
>>
>>> May be, additional option, specifying the shift would be better. 
>>> With convention that if offset+length exceeds disk size, length 
>>> should be recalculated as disk_size-offset.
>> I don't think we should do that. We already have clear semantics that 
>> prevent operations beyond the end of the disk. Again, just break the 
>> command up into multipl commands. No great hardship.
>>
>
> I agree that requests larger than disk size are ugly.. But splitting 
> request brings me again to idea of having separate command or flag for 
> clearing the whole disk without that dance. Server may report 
> availability of this/flag command only if target driver supports fast 
> write_zeroes (qcow2 in our case).
>

Also, such flag may be used to satisfy all needs:

flag BIG_REQUEST is set and length = 0    ->    request on the whole 
disk, offset must be 0
flag BIG_REQUEST is set and length > 0    ->    request on 
(offset*block_size, length*block_size), length*block_size must be <= 
disk_size
flag BIG_REQUEST is unset     ->    usual request on (offset, length)

-- 
Best regards,
Vladimir