Am 07.11.2017 um 08:18 hat wang.guan...@zte.com.cn geschrieben: > hello > > > if we create a qcow2 file on a block dev. > > > we can,t get the right disk size by qemu-img info。 > > > > > > > [root@host-120-79 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 > > [root@host-120-79 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
