qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] about qemu-img info on block dev


From: Kevin Wolf
Subject: Re: [Qemu-block] about qemu-img info on block dev
Date: Tue, 7 Nov 2017 10:15:06 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

Am 07.11.2017 um 08:18 hat address@hidden geschrieben:
> hello
> 
> 
> if we create a qcow2 file on a block dev.
> 
> 
> we can,t get the right disk size by qemu-img info。
> 
> 
> 
> 
> 
> 
> address@hidden qemu]# ./qemu-img create -f qcow2 /dev/zs/lvol0 1G
> 
> Formatting '/dev/zs/lvol0', fmt=qcow2 size=1073741824 cluster_size=65536 
> lazy_refcounts=off refcount_bits=16
> 
> address@hidden qemu]# ./qemu-img info /dev/zs/lvol0 
> 
> image: /dev/zs/lvol0
> 
> file format: qcow2
> 
> virtual size: 1.0G (1073741824 bytes)
> 
> disk size: 0
> 
> cluster_size: 65536
> 
> Format specific information:
> 
>     compat: 1.1
> 
>     lazy refcounts: false
> 
>     refcount bits: 16
> 
>     corrupt: false
> 
> 
> 
> 
> 
> 
> Then we get disk size from L1 table and L2 table in 
> qcow2_get_allocated_file_size.
> 
> 
> May be we can submit the patch to qemu master??

No, qcow2 is the wrong layer to do this. If anything,
raw_get_allocated_file_size() could be changed to return the full file
size for block devices. However, even this is not necessarily the right
number, the block device could actually be thin provisioned and the
kernel doesn't tell us how many blocks are actually allocated. So I
think 0 for "we don't know" is in fact the right answer.

Kevin



reply via email to

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