qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH] qcow2: add allocated-size to image specific inf


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH] qcow2: add allocated-size to image specific info
Date: Thu, 18 May 2017 15:33:32 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

18.05.2017 15:10, Kevin Wolf wrote:
Am 18.05.2017 um 13:04 hat Vladimir Sementsov-Ogievskiy geschrieben:
18.05.2017 13:25, Kevin Wolf wrote:
Am 18.05.2017 um 12:09 hat Vladimir Sementsov-Ogievskiy geschrieben:
Shows, how much data qcow2 allocates in underlying file. This should
be helpful on non-sparse file systems, when qemu-img info "disk size"
doesn't provide this information.

Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
---
Hi all.

Here is an allocated-size feature for qemu-img info.
I'm not a fan of loading all L2 tables (can take some time) for
'qemu-img info' (which should be very quick). Why isn't the qemu-img
check output good enough?

Kevin

$ ./qemu-img check /tmp/test.qcow2
No errors were found on the image.
16164/491520 = 3.29% allocated, 11.98% fragmented, 0.00% compressed clusters
Image end offset: 1060044800
$ ./qemu-img check --output=json /tmp/test.qcow2
{
     "image-end-offset": 1060044800,
     "total-clusters": 491520,
     "check-errors": 0,
     "allocated-clusters": 16164,
     "filename": "/tmp/test.qcow2",
     "format": "qcow2",
     "fragmented-clusters": 1937
}
It is not the same, it shows guest clusters, but we need host
clusters - including all metadata, dirty bitmaps, snapshots, etc..
Ah, right. But isn't that exactly the "disk size" (actual-size in JSON)
from qemu-img info? Your commit message mentions non-sparse filesystems
(which one?), but why wouldn't "disk size" provide this information
there?

it goes through bs->file, as qcow2 doesn't have .bdrv_get_allocated_file_size, so in case of raw
bs->file we just call fstat on bs->file.


The one case where it doesn't work is if you store a qcow2 image on a
raw block device (this is something that oVirt does). In that case,
you can't benefit from sparseness and disk space is used for a cluster
in the middle even if its refcount is 0. oVirt uses "image-end-offset"
to get the size of the first of the block device that is actually in use
by the image.

Our customer has a distributed fs not maintaining sparse files. We need this stat, about how many holes we have in qcow2 image.


What is your exact use case? Maybe this helps me understand the exact
kind of information that you need.

Kevin


--
Best regards,
Vladimir




reply via email to

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