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

[Vladimir Sementsov-Ogievskiy]

On 24.09.2016 19:49, Alex Bligh wrote:
> > On 24 Sep 2016, at 17:42, Vladimir Sementsov-Ogievskiy <address@hidden> wrote:
> >
> > On 24.09.2016 19:31, Alex Bligh wrote:
> > > > On 24 Sep 2016, at 13:06, Vladimir Sementsov-Ogievskiy <address@hidden> 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).

--
Best regards,
Vladimir