qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] qemu-img: make sure contain th


From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] qemu-img: make sure contain the consecutive number of zero bytes
Date: Tue, 25 Apr 2017 22:01:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

On 25.04.2017 03:50, 858585 jemmy wrote:
> On Mon, Apr 24, 2017 at 10:43 PM, Eric Blake <address@hidden> wrote:
>> On 04/23/2017 09:33 AM, address@hidden wrote:
>>> From: Lidong Chen <address@hidden>
>>>
>>> is_allocated_sectors_min don't guarantee to contain the
>>> consecutive number of zero bytes. this patch fixes this bug.
>>
>> This message was sent without an 'In-Reply-To' header pointing to a 0/2
>> cover letter.  When sending a series, please always thread things to a
>> cover letter; you may find 'git config format.coverletter auto' to be
>> helpful.
> 
> Thanks for your kind advises.
> 
>>
>>>
>>> Signed-off-by: Lidong Chen <address@hidden>
>>> ---
>>>  qemu-img.c | 11 ++++++-----
>>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/qemu-img.c b/qemu-img.c
>>> index b220cf7..df6d165 100644
>>> --- a/qemu-img.c
>>> +++ b/qemu-img.c
>>> @@ -1060,9 +1060,9 @@ static int is_allocated_sectors(const uint8_t *buf, 
>>> int n, int *pnum)
>>>  }
>>>
>>>  /*
>>> - * Like is_allocated_sectors, but if the buffer starts with a used sector,
>>> - * up to 'min' consecutive sectors containing zeros are ignored. This 
>>> avoids
>>> - * breaking up write requests for only small sparse areas.
>>> + * Like is_allocated_sectors, but up to 'min' consecutive sectors
>>> + * containing zeros are ignored. This avoids breaking up write requests
>>> + * for only small sparse areas.
>>>   */
>>>  static int is_allocated_sectors_min(const uint8_t *buf, int n, int *pnum,
>>>      int min)
>>> @@ -1071,11 +1071,12 @@ static int is_allocated_sectors_min(const uint8_t 
>>> *buf, int n, int *pnum,
>>>      int num_checked, num_used;
>>>
>>>      if (n < min) {
>>> -        min = n;
>>> +        *pnum = n;
>>> +        return 1;
>>>      }
>>>
>>>      ret = is_allocated_sectors(buf, n, pnum);
>>> -    if (!ret) {
>>> +    if (!ret && *pnum >= min) {
>>
>> I seem to recall past attempts to try and patch this function, which
>> were then turned down, although I haven't scrubbed the archives for a
>> quick URL to point to. I'm worried that there are more subtleties here
>> than what you realize.
> 
> Hi Eric:
> Do you mean this URL?
> https://lists.gnu.org/archive/html/qemu-block/2017-01/msg00306.html
> 
> But I think the code is not consistent with qemu-img --help.
> qemu-img --help
>   '-S' indicates the consecutive number of bytes (defaults to 4k) that must
>        contain only zeros for qemu-img to create a sparse image during
>        conversion. If the number of bytes is 0, the source will not be
> scanned for
>        unallocated or zero sectors, and the destination image will always be
>        fully allocated.
> 
> another reason:
> if s->has_zero_init is 1(the qcow2 image which have backing_file), the empty
> space at the beginning of the buffer still need write and invoke
> blk_co_pwrite_zeroes.

Right, that is indeed a reason that we may want to behave differently in
these cases. But in other cases this is less efficient.

> and split a single write operation into two just because there is small empty
> space at the beginning.
And then there's the fact that, in my opinion, this is actually a
problem at qcow2 level. Some people are working on improving this (see
e.g. Berto's subcluster RFC, which would allow us to implement
bdrv_co_pwrite_zeroes() below cluster granularity).

All in all, I don't think you can generically circumvent this issue here
for all block drivers. The rule we'd have to implement here is: If some
part of a cluster (to be written) is zero and another is not, we should
write the whole cluster. If a whole cluster is zero, we should issue a
write-zeroes request. But that would mean to check where some buffer
passes a cluster boundary and so on, and on top of this all of it is
qcow2-specific; so there goes the genericity...

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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