qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCHv3 1/2] qemu-img: find the highest offset in use


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCHv3 1/2] qemu-img: find the highest offset in use during check
Date: Fri, 25 Jan 2013 09:09:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 01/21/2013 10:52 AM, Eric Blake wrote:
> On 01/21/2013 10:03 AM, Kevin Wolf wrote:
>> Am 21.01.2013 17:27, schrieb Eric Blake:
>>> On 01/21/2013 07:25 AM, Federico Simoncelli wrote:
>>>> This patch adds the support for reporting the highest offset in use by
>>>> an image. This is particularly useful after a conversion (or a rebase)
>>>> where the destination is a block device in order to find the actual
>>>> amount of space in use.
> 
>>>> +    if (result.highest_offset > 0) {
>>>> +        printf("Highest offset in use: %" PRId64 "\n", 
>>>> result.highest_offset);
>>>
>>> This output message feels off by one.  Either you need to subtract 1
>>> from res->highest_offset to get the address of the last used byte, or
>>> you need to document it as the first unused byte, or instead of calling
>>> it 'highest offset', you should call it 'used bytes' (except that with
>>> sparse files, it's hard to argue that all earlier bytes were 'used').
>>
>> Good point. I think the number is what we wanted, and what users are
>> interested in is probably "used bytes" rather than "first unused byte".
>> Maybe we can find a better word for "used" (it has the same problem in
>> all three contexts), but I can't think of one off the top of my head.
> 
> "Allocation" alone isn't good (because of sparse files, not all earlier
> bytes are allocated).  But maybe "Offset of unallocated tail: ..."
> works, to make it clear that there may be other unallocated portions
> earlier, but that all bytes at the listed offset and beyond are
> unallocated.  For a file that is completely allocated, or even for a
> sparse file but with no unallocated tail, the value would be the same as
> the file capacity.

On IRC, we decided the name result.image_end_offset feels better.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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