[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
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, (continued)
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, Eric Blake, 2017/04/24
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, Philippe Mathieu-Daudé, 2017/04/24
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, Eric Blake, 2017/04/24
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, Eric Blake, 2017/04/24
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, 858585 jemmy, 2017/04/24
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, Max Reitz, 2017/04/25
- Re: [Qemu-block] [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors, 858585 jemmy, 2017/04/26
Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] qemu-img: make sure contain the consecutive number of zero bytes, Eric Blake, 2017/04/24