qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] write_zeroes/trim on the whole disk
Date: Sat, 24 Sep 2016 20:33:03 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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 <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).


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]