import thin provisioned disks with image upload
On Thu, Dec 7, 2017 at 1:28 AM, Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Dec 7, 2017 at 1:22 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Wed, Dec 6, 2017 at 11:42 PM, Nir Soffer <nsoffer@redhat.com> wrote:
BTW: I notice that the disk seems preallocated even if original qcow2 is thin... is this expected? This obviously also impacts the time to upload (20Gb virtual disk with actual 1.2Gb occupied needs the time equivalent for full 20Gb...)
We upload exactly the file you provided, there is no way we can upload 20G from 1.2G file :-)
But the upload process at a medium rate of 40-50MB/s has last about 9 minutes that confirms the 20Gb size The disk at source has been created as virtio type and format qcow2 from virt-manager and then only installed a CentOS 7.2 OS with infrastructure server configuration. Apart from qemu-img also ls: # ls -lhs c7lab1.qcow2 1.3G -rw------- 1 root root 21G Dec 6 23:05 c7lab1.qcow2
The fiile size is 21G - matching what you see. This is the size we upload.
I changed the subject to better address and track the thread.. You are not convincing me... The term "file size" is ambiguous in this context... If I take a disk that was born on this oVirt environment itself I have this: https://drive.google.com/file/d/1Dtb69EKa8adNYiwUDs2d-plSMZIM0Bzr/view?usp=s... that shows that is thin provisioned Its id shown here: https://drive.google.com/file/d/1PvLjJVQ3JR4_6v5Da7ATac5ReEObxH-A/view?usp=s... If I go and check on my exported file system I get this [root@ovirt01 NFS_DOMAIN]# find . -name "3c68d43f-0f28-4564-b557-d390a125daa6" ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6 [root@ovirt01 NFS_DOMAIN]# ls -lsh ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6 total 8.6G 8.6G -rw-rw----. 1 vdsm kvm 10G Dec 7 08:42 09ad8e53-0b22-4fe3-b718-d14352b8290a 1.0M -rw-rw----. 1 vdsm kvm 1.0M May 1 2016 09ad8e53-0b22-4fe3-b718-d14352b8290a.lease 4.0K -rw-r--r--. 1 vdsm kvm 317 Jun 21 10:41 09ad8e53-0b22-4fe3-b718-d14352b8290a.meta [root@ovirt01 NFS_DOMAIN]# qemu-img info ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6/09ad8e53-0b22-4fe3-b718-d14352b8290a image: ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6/09ad8e53-0b22-4fe3-b718-d14352b8290a file format: raw virtual size: 10G (10737418240 bytes) disk size: 8.5G [root@ovirt01 NFS_DOMAIN]# So it seems it is raw/sparse https://www.ovirt.org/documentation/admin-guide/chap-Virtual_Machine_Disks/
1.3G is the used size on the file system, we cannot upload only used blocks. qemu-img info "Disk size" is not the file size the the used size, not useful for upload.
Why not? You can detect the format of source and use a similar strategy of the bugzilla I'm referring (see below) Or couldn't you use something like rsync -av --sparse source target if the target is NFS?
Maybe this file was crated with preallocation=full?
In virt-manager there is not this logic by default. The default format is qcow2/sparse When you create/add a disk you can choose "Select or create custom storage": https://drive.google.com/file/d/1gAwjAG5aRFC5fFgkoZXT5wINvQnov88p/view?usp=s... And then choose a format between: raw, qcow, qcow2, qed, vmdk, vpc, vdi In my case it was the default one, so qcow2, as qemu-img correctly detects.
First message at beginning of upload:
2017-12-06 23:09:50,183+0100 INFO (jsonrpc/4) [vdsm.api] START createVolume(sdUUID=u'572eabe7-15d0-42c2-8fa9-0bd773e22e2e', spUUID=u'00000001-0001-0001-0001-000000000343', imgUUID=u'251063f6-5570-4bdc-b28f-21e82aa5e185', size=u'22548578304', volFormat=4, preallocate=2, diskType=2, volUUID=u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', desc=u'{"DiskAlias":"c7lab1","DiskDescription":""}', srcImgUUID=u'00000000-0000-0000-0000-000000000000', srcVolUUID=u'00000000-0000-0000-0000-000000000000', initialSize=None) from=192.168.1.212,56846, flow_id=18c6bd3b-76ab-45f9-b8c7-09c727f44c91, task_id=e7cc67e6-4b61-4bb3-81b1-6bc687ea5ee9 (api:46)
In this bugzilla, that is related to export from NFS to block: https://bugzilla.redhat.com/show_bug.cgi?id=1358717 it seems to understand, from a comment of Maor, that preallocate=2 --> sparse what are instead the possible values of volFormat and their decodification? In my case it detects volFormat=4, Could it be something similar to the bugzilla above? Can it change anything if exporting with NFS 4.2 or using oVirt 4.2? I think that if one has big qcow2 disk files that he/she desire to migrate into oVirt, the process could be optimized Thanks, Gianluca
On Thu, Dec 7, 2017 at 10:15 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Dec 7, 2017 at 1:28 AM, Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Dec 7, 2017 at 1:22 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Wed, Dec 6, 2017 at 11:42 PM, Nir Soffer <nsoffer@redhat.com> wrote:
BTW: I notice that the disk seems preallocated even if original qcow2 is thin... is this expected? This obviously also impacts the time to upload (20Gb virtual disk with actual 1.2Gb occupied needs the time equivalent for full 20Gb...)
We upload exactly the file you provided, there is no way we can upload 20G from 1.2G file :-)
But the upload process at a medium rate of 40-50MB/s has last about 9 minutes that confirms the 20Gb size The disk at source has been created as virtio type and format qcow2 from virt-manager and then only installed a CentOS 7.2 OS with infrastructure server configuration. Apart from qemu-img also ls: # ls -lhs c7lab1.qcow2 1.3G -rw------- 1 root root 21G Dec 6 23:05 c7lab1.qcow2
The fiile size is 21G - matching what you see. This is the size we upload.
I changed the subject to better address and track the thread.. You are not convincing me...
Trying harder...
The term "file size" is ambiguous in this context...
It is not. file size is what you get from stat: $ truncate -s 1g empty $ stat empty File: 'empty' Size: 1073741824 Blocks: 0 IO Block: 4096 regular file ... $ qemu-img info empty image: empty file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 The value "disk size" used by qemu-img is confusing and not useful when you want to transfer the file to another host. I don't know why qemu-img display this value instead of the actual file size, adding qemu-block mailing list in case someone can explain this. When you upload or download this file, you will transfer 1g of zeros.
If I take a disk that was born on this oVirt environment itself I have this:
https://drive.google.com/file/d/1Dtb69EKa8adNYiwUDs2d-plSMZIM0Bzr/view?usp=s...
that shows that is thin provisioned Its id shown here:
https://drive.google.com/file/d/1PvLjJVQ3JR4_6v5Da7ATac5ReEObxH-A/view?usp=s...
If I go and check on my exported file system I get this
[root@ovirt01 NFS_DOMAIN]# find . -name "3c68d43f-0f28-4564-b557-d390a125daa6"
./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6 [root@ovirt01 NFS_DOMAIN]# ls -lsh ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6 total 8.6G 8.6G -rw-rw----. 1 vdsm kvm 10G Dec 7 08:42 09ad8e53-0b22-4fe3-b718-d14352b8290a 1.0M -rw-rw----. 1 vdsm kvm 1.0M May 1 2016 09ad8e53-0b22-4fe3-b718-d14352b8290a.lease 4.0K -rw-r--r--. 1 vdsm kvm 317 Jun 21 10:41 09ad8e53-0b22-4fe3-b718-d14352b8290a.meta
[root@ovirt01 NFS_DOMAIN]# qemu-img info ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6/09ad8e53-0b22-4fe3-b718-d14352b8290a image: ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-d390a125daa6/09ad8e53-0b22-4fe3-b718-d14352b8290a file format: raw virtual size: 10G (10737418240 bytes) disk size: 8.5G [root@ovirt01 NFS_DOMAIN]#
So it seems it is raw/sparse https://www.ovirt.org/documentation/admin-guide/chap-Virtual_Machine_Disks/
Yes this is raw sparse file.
1.3G is the used size on the file system, we cannot upload only used
blocks. qemu-img info "Disk size" is not the file size the the used size, not useful for upload.
Why not? You can detect the format of source and use a similar strategy of the bugzilla I'm referring (see below) Or couldn't you use something like
That bug is not related. It was about converting raw sparse format to qcow2. In 4.2 we use qemu-img map and the same algorithm used in qemu to estimate the required size needed to convert raw volume to qcow2 volume. For transferring images over http, there is no way to avoid sending unused blocks, except compression.
rsync -av --sparse source target
You can use rsync to transfer images if you like, but we support only http.
if the target is NFS?
Maybe this file was crated with preallocation=full?
In virt-manager there is not this logic by default. The default format is qcow2/sparse When you create/add a disk you can choose "Select or create custom storage":
https://drive.google.com/file/d/1gAwjAG5aRFC5fFgkoZXT5wINvQnov88p/view?usp=s...
And then choose a format between: raw, qcow, qcow2, qed, vmdk, vpc, vdi
In my case it was the default one, so qcow2, as qemu-img correctly detects.
I tested creating qcow2 files with virt manager, and it seems to use the preallocation=metadata by default (behind your back), I guess for improving performance in some cases. oVirt doe not use this option so we don't have this issue when downloading files. Here example of image created by virt-manager: # ls -lsh fedora26-2.img 3.4M -rw-------. 1 root root 21G Dec 7 21:36 fedora26-2.img # qemu-img info fedora26-2.img image: fedora26-2.img file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 3.3M cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false And here is same image as ovirt create images: # qemu-img create -f qcow2 test.qcow2 20g Formatting 'test.qcow2', fmt=qcow2 size=21474836480 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 # qemu-img info test.qcow2 image: test.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false # ls -lhs test.qcow2 196K -rw-r--r--. 1 root root 193K Dec 7 21:40 test.qcow2 So to download this image you need to transfer only 196k of data, not 20g. We can get the same results as virt-manager if we use preallocation=metadata: # qemu-img create -f qcow2 -o preallocation=metadata test-preallocation-metadata.qcow2 20g Formatting 'test-preallocation-metadata.qcow2', fmt=qcow2 size=21474836480 encryption=off cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16 # qemu-img info test-preallocation-metadata.qcow2 image: test-preallocation-metadata.qcow2 file format: qcow2 virtual size: 20G (21474836480 bytes) disk size: 3.3M cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false # ls -lhs test-preallocation-metadata.qcow2 3.4M -rw-r--r--. 1 root root 21G Dec 7 21:42 test-preallocation-metadata.qcow2 First message at beginning of upload:
2017-12-06 23:09:50,183+0100 INFO (jsonrpc/4) [vdsm.api] START createVolume(sdUUID=u'572eabe7-15d0-42c2-8fa9-0bd773e22e2e', spUUID=u'00000001-0001-0001-0001-000000000343', imgUUID=u'251063f6-5570-4bdc-b28f-21e82aa5e185', size=u'22548578304', volFormat=4, preallocate=2, diskType=2, volUUID=u'77aacfb3-9e67-4ad2-96f6-242b5ba4d9e0', desc=u'{"DiskAlias":"c7lab1","DiskDescription":""}', srcImgUUID=u'00000000-0000-0000-0000-000000000000', srcVolUUID=u'00000000-0000-0000-0000-000000000000', initialSize=None) from=192.168.1.212,56846, flow_id=18c6bd3b-76ab-45f9-b8c7-09c727f44c91, task_id=e7cc67e6-4b61-4bb3-81b1-6bc687ea5ee9 (api:46)
In this bugzilla, that is related to export from NFS to block: https://bugzilla.redhat.com/show_bug.cgi?id=1358717
it seems to understand, from a comment of Maor, that preallocate=2 --> sparse
what are instead the possible values of volFormat and their decodification? In my case it detects volFormat=4,
Could it be something similar to the bugzilla above? Can it change anything if exporting with NFS 4.2 or using oVirt 4.2?
I think that if one has big qcow2 disk files that he/she desire to migrate into oVirt, the process could be optimized
To optimize the import of images with unneeded preallocation, you can convert them to unallocated and compressed images as I showed in the previous mail. Here is an example with the preallocated images, like the one from virt-manager. I'll create file with some data - I'm using data that will compress well to make the example more convincing :-) # dd if=/dev/zero bs=8M count=128 | tr "\0" "\1" > image.raw 128+0 records in 128+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.88171 s, 571 MB/s Add some empty space: # truncate -s 10g image.raw # ls -lhs image.raw 1.1G -rw-r--r--. 1 root root 10G Dec 7 22:01 image.raw Now lest create a qcow2 preallocated image like virt-manger does: # qemu-img convert -f raw -O qcow2 -o preallocation=metadata image.raw image-preallocated-metadata.qcow2 # qemu-img info image-preallocated-metadata.qcow2 image: image-preallocated-metadata.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 1.0G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false # ls -lhs image* 1.1G -rw-r--r--. 1 root root 11G Dec 7 22:02 image-preallocated-metadata.qcow2 1.1G -rw-r--r--. 1 root root 10G Dec 7 22:01 image.raw Finally, create a compressed qcow2, optimized for upload: # qemu-img convert -c -f qcow2 -O qcow2 image-preallocated-metadata.qcow2 image-preallocated-metadata-optimized.qcow2 # qemu-img info image-preallocated-metadata-optimized.qcow2 image: image-preallocated-metadata-optimized.qcow2 file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 1.6M cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false # ls -lhs image* 1.6M -rw-r--r--. 1 root root 1.7M Dec 7 22:04 image-preallocated-metadata-optimized.qcow2 1.1G -rw-r--r--. 1 root root 11G Dec 7 22:02 image-preallocated-metadata.qcow2 1.1G -rw-r--r--. 1 root root 10G Dec 7 22:01 image.raw All the images contain exactly the same data. Now, how can we optimize your image on upload? we can't. When uploading from the UI, our code run in the browser and we don't have access to your file system. When using the oVirt SDK, you write the code for uploading so you can do the conversion if want to save upload time and bandwidth and can spend the time to do the conversion. We can provide an upload command line tool that will convert and compress images before upload, and will use the oVirt SDK to upload the images. But I think it will be simpler and easier to maintain to support compression when uploading or downloading data. This is already supported by browsers and common tools like curl, and it works with any file format without conversion. I hope I convinced you this time ;-) Nir
Thanks, Gianluca
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ldHd2lCWj7jKEETVuI81oTog5UxEokqf6 Content-Type: multipart/mixed; boundary="Rcw9BITPPwikllx1VkJV7F1EW1x5wWi88"; protected-headers="v1" From: Eric Blake <eblake@redhat.com> To: Nir Soffer <nsoffer@redhat.com>, Gianluca Cecchi <gianluca.cecchi@gmail.com>, "qemu-block@nongnu.org" <qemu-block@nongnu.org> Cc: Paolo Margara <paolo.margara@polito.it>, users <users@ovirt.org> Message-ID: <9ae28d4c-35e7-c7f6-bbae-6f826a7007ef@redhat.com> Subject: Re: [Qemu-block] import thin provisioned disks with image upload References: <CAG2kNCy9Ok=rqbAi4i+XfWGoF=pSjugsAv=iP=whgf7QPtJVsA@mail.gmail.com> <CAMRbyyu4rchkT8WYE-QWwkFZFKGaKtFzoLPX1_jkwYDhNBn0Mg@mail.gmail.com> In-Reply-To: <CAMRbyyu4rchkT8WYE-QWwkFZFKGaKtFzoLPX1_jkwYDhNBn0Mg@mail.gmail.com> --Rcw9BITPPwikllx1VkJV7F1EW1x5wWi88 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/07/2017 02:33 PM, Nir Soffer wrote:
$ truncate -s 1g empty =20 $ stat empty File: 'empty' Size: 1073741824 Blocks: 0 IO Block: 4096 regular file ... =20 $ qemu-img info empty image: empty file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 =20 The value "disk size" used by qemu-img is confusing and not useful when you want to transfer the file to another host. =20 I don't know why qemu-img display this value instead of the actual file size, adding qemu-block mailing list in case someone can explain this.
For regular files, qemu is reporting the stat Blocks value (a completely sparse file occupies 0 blocks, and therefore uses 0 bytes of the host filesystem).
=20 When you upload or download this file, you will transfer 1g of zeros.
Well, depending on whether your transfer mechanism has optimizations for transferring holes efficiently, you may not have to send 1G of zeroes over the wire; but yes, the receiving end must reconstruct a file containing 1G of zeroes (even if that reconstruction is also sparse, and occupies 0 blocks of the file system).
If I go and check on my exported file system I get this
[root@ovirt01 NFS_DOMAIN]# find . -name "3c68d43f-0f28-4564-b557-d390a125daa6"
./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-= d390a125daa6 [root@ovirt01 NFS_DOMAIN]# ls -lsh ./572eabe7-15d0-42c2-8fa9-0bd773e22e2e/images/3c68d43f-0f28-4564-b557-= d390a125daa6 total 8.6G 8.6G -rw-rw----. 1 vdsm kvm 10G Dec 7 08:42 09ad8e53-0b22-4fe3-b718-d14352b8290a
=20 Yes this is raw sparse file. =20 =20
1.3G is the used size on the file system, we cannot upload only used
blocks.
You have to understand something about the way file systems work. Just because the filesystem reports 1.3G used, does NOT mean that 1.3G is contiguous; depending on how scatter-shot its allocation patterns have been, and the minimum granularity for holes in the host filesystem, there could very well be gaps that the guest is reporting as unused but which still contribute towards the in-use block count reported by the hos= t. Furthermore, when you delete a file, most filesystems do not immediately rewrite the underlying storage back to 0, but just update metadata in the filesystem to state that the storage can be reused later for a new file. The TRIM operation on filesystems can help reclaim some of that (now-unused) space, and more and more filesystems are starting to support the Linux ioctls for punching holes in the middle of existing files to quit occupying blocks. But the fact that the host filesystem claims 8.6G of used blocks is a typical symptom of not having TRIM'ed the guest filesystem recently, or a case where guest TRIMs do not reach through all the layers into a host hole-punching operation.
qemu-img info "Disk size" is not the file size the the used size, not=
useful for upload.
Disk size of a raw file is how many host blocks are currently in use; but you are correct that it does not necessarily tell you how much data the guest filesystem is currently reporting as used - on the other hand, it is a good conservative upper bound for how much storage you need to reproduce the same bit pattern on the destination (even if many of the bits don't need to be reproduced, because the guest filesystem didn't care about them) - but only insofar as you can preserve sparseness of the portions of the file that are holes in the source. You may also be interested in the virt-sparsify tool from libguestfs, which is very good at squeezing out unneeded space from an image in order to get a smaller version that still produces the same content that the guest cares about. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org --Rcw9BITPPwikllx1VkJV7F1EW1x5wWi88-- --ldHd2lCWj7jKEETVuI81oTog5UxEokqf6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAlopsDYACgkQp6FrSiUn Q2pUSQf/YZsg66xGecIOMQeBYLseTE6cgA42ndzXV8PX6ec6yxuYQBLt5rX96DAt aX84RmKFd+o84j4MRdTgReP7hkeL368vIgVK6CIyrXWA0pViXWgas0N6GpuVSPxr 4gbHcHwUfc0lq4eDeaDnFb5NSt5Sohrqc3nM8/VDsUBarfxpwjwNb300kwWEXndc 1H0WbCNMr7Ds/op/CZHTS+wN0oDsT9pi2gLhdPr6M5g+ZICwqGMl4OH6zPWX4IbC fP83l5jhl+21g03F9NaklhOpo1GanM7kOjX7E0aF4uO3QqJSNs2xHSCwHmikxzQ7 2keT7opN9JvGA1wj5asbZkPy8YbLFw== =FMsq -----END PGP SIGNATURE----- --ldHd2lCWj7jKEETVuI81oTog5UxEokqf6--
On Thu, Dec 7, 2017 at 9:33 PM, Nir Soffer <nsoffer@redhat.com> wrote:
For transferring images over http, there is no way to avoid sending unused blocks, except compression.
OK, understood
Maybe this file was crated with preallocation=full?
In virt-manager there is not this logic by default. The default format is qcow2/sparse When you create/add a disk you can choose "Select or create custom storage": https://drive.google.com/file/d/1gAwjAG5aRFC5fFgkoZXT5wINvQnov 88p/view?usp=sharing
And then choose a format between: raw, qcow, qcow2, qed, vmdk, vpc, vdi
In my case it was the default one, so qcow2, as qemu-img correctly detects.
I tested creating qcow2 files with virt manager, and it seems to use the preallocation=metadata by default (behind your back), I guess for improving performance in some cases. oVirt doe not use this option so we don't have this issue when downloading files.
Ah, ok. I didn't know about this preallocation option of qemu-img Does your example mean that by default oVirt uses preallocation=off when creating thin provisoned disks?
I hope I convinced you this time ;-)
Nir
Yes :- ] and thanks for the deep an detailed explanation, Nir Thanks also to Eric for his comments in the other reply Gianluca
On Fri, Dec 8, 2017 at 1:35 AM Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Thu, Dec 7, 2017 at 9:33 PM, Nir Soffer <nsoffer@redhat.com> wrote:
For transferring images over http, there is no way to avoid sending unused blocks, except compression.
OK, understood
Maybe this file was crated with preallocation=full?
In virt-manager there is not this logic by default. The default format is qcow2/sparse When you create/add a disk you can choose "Select or create custom storage":
https://drive.google.com/file/d/1gAwjAG5aRFC5fFgkoZXT5wINvQnov88p/view?usp=s...
And then choose a format between: raw, qcow, qcow2, qed, vmdk, vpc, vdi
In my case it was the default one, so qcow2, as qemu-img correctly detects.
I tested creating qcow2 files with virt manager, and it seems to use the preallocation=metadata by default (behind your back), I guess for improving performance in some cases. oVirt doe not use this option so we don't have this issue when downloading files.
Ah, ok. I didn't know about this preallocation option of qemu-img Does your example mean that by default oVirt uses preallocation=off when creating thin provisoned disks?
Correct, we use the default.
I hope I convinced you this time ;-)
Nir
Yes :- ] and thanks for the deep an detailed explanation, Nir
Thanks also to Eric for his comments in the other reply
Gianluca
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bhR347vL55SA6RBIfMovKtx9QhoMUo0mw Content-Type: multipart/mixed; boundary="Rex9njBKm0vVDcsej8W9ig7Xt3vd8hFbN"; protected-headers="v1" From: Max Reitz <mreitz@redhat.com> To: Nir Soffer <nsoffer@redhat.com>, Gianluca Cecchi <gianluca.cecchi@gmail.com>, "qemu-block@nongnu.org" <qemu-block@nongnu.org> Cc: Paolo Margara <paolo.margara@polito.it>, users <users@ovirt.org> Message-ID: <5c36d206-1e28-9376-dd68-3675793af55f@redhat.com> Subject: Re: [Qemu-block] import thin provisioned disks with image upload References: <CAG2kNCy9Ok=rqbAi4i+XfWGoF=pSjugsAv=iP=whgf7QPtJVsA@mail.gmail.com> <CAMRbyyu4rchkT8WYE-QWwkFZFKGaKtFzoLPX1_jkwYDhNBn0Mg@mail.gmail.com> In-Reply-To: <CAMRbyyu4rchkT8WYE-QWwkFZFKGaKtFzoLPX1_jkwYDhNBn0Mg@mail.gmail.com> --Rex9njBKm0vVDcsej8W9ig7Xt3vd8hFbN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-12-07 21:33, Nir Soffer wrote: [...]
=20 Trying harder... =C2=A0 =20 The term "file size" is ambiguous in this context... =20 =20 It is not. file size is what you get from stat: =20 $ truncate -s 1g empty =20 $ stat empty=C2=A0 =C2=A0 File: 'empty' =C2=A0 Size: 1073741824Blocks: 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IO B= lock: 4096=C2=A0 =C2=A0regular file =C2=A0 ... =20 $ qemu-img info empty image: empty file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 =20 The value "disk size" used by qemu-img is confusing and not useful when you want to transfer the file to another host. =20 I don't know why qemu-img display this value instead of the actual file size, adding qemu-block mailing list in case someone can explain this.
Because I still think it's ambiguous. $ qemu-img create -f raw empty 1G Formatting 'empty', fmt=3Draw size=3D1073741824 $ qemu-img info empty image: empty file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 $ LANG=3DC stat empty File: empty Size: 1073741824 Blocks: 0 IO Block: 4096 regular file [...] $ ls -s empty 0 empty $ du -h empty 0 empty $ ls -l empty -rw-r--r--. 1 maxx maxx 1073741824 8. Dez 16:20 empty What "stat" reports as "size" I'd call the length (what qemu-img info calls "virtual size" for raw images). What I (and qemu-img info) call "size" is how much disk space is actually used. And both ls -s and du agree that it's 0 bytes in this case. By the way, yes, "stat" has a different definition of "size", so that seems wrong. But I argue that the "ls" option is called "--size", so there's a conflict already and qemu-img info is not the first tool to disagree with stat on this. Max --Rex9njBKm0vVDcsej8W9ig7Xt3vd8hFbN-- --bhR347vL55SA6RBIfMovKtx9QhoMUo0mw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQFGBAEBCAAwFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAloqrm0SHG1yZWl0ekBy ZWRoYXQuY29tAAoJEPQH2wBh1c9Ap4wH/3X1J+p8aum+Mp+Z7zMLpxwp4dqqfvhv +yzMUabVkS4hOlow6PmeAyI4boW/pPOnRTnTMBTVdPXf50OnLYJovXSdwkInsaPy 66UindBWKRvAH0FQxOkuBSvtj2sks0T+PLv+kLGlnFQ5FVYHVUNflm3KKyyR8Sgc VL2ptdL8BO4g0SFqwT0svivlrsCCTpcywCoA8cBqGm9SH2gNYyAvC10zG0pkrLSm rIEqo/RTgT24vlnPo5a699oH/c82oK5bB5h7Tx+yOHsnJy2tunb/xU5zHt19yehg bLX4k4POVoE1sFO2HGq92nt0pQR6Efk+aOGX1f6Y1p4QG7EPlnItp6A= =tS9i -----END PGP SIGNATURE----- --bhR347vL55SA6RBIfMovKtx9QhoMUo0mw--
On Fri, Dec 8, 2017 at 5:23 PM Max Reitz <mreitz@redhat.com> wrote:
On 2017-12-07 21:33, Nir Soffer wrote:
[...]
Trying harder...
The term "file size" is ambiguous in this context...
It is not. file size is what you get from stat:
$ truncate -s 1g empty
$ stat empty File: 'empty' Size: 1073741824Blocks: 0 IO Block: 4096 regular file ...
$ qemu-img info empty image: empty file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0
The value "disk size" used by qemu-img is confusing and not useful when you want to transfer the file to another host.
I don't know why qemu-img display this value instead of the actual file size, adding qemu-block mailing list in case someone can explain this.
Because I still think it's ambiguous.
$ qemu-img create -f raw empty 1G Formatting 'empty', fmt=raw size=1073741824 $ qemu-img info empty image: empty file format: raw virtual size: 1.0G (1073741824 bytes) disk size: 0 $ LANG=C stat empty File: empty Size: 1073741824 Blocks: 0 IO Block: 4096 regular file [...] $ ls -s empty 0 empty $ du -h empty 0 empty $ ls -l empty -rw-r--r--. 1 maxx maxx 1073741824 8. Dez 16:20 empty
What "stat" reports as "size" I'd call the length (what qemu-img info calls "virtual size" for raw images).
raw images are not an issue since the virtual size is the file size.
What I (and qemu-img info) call "size" is how much disk space is actually used. And both ls -s and du agree that it's 0 bytes in this case.
By the way, yes, "stat" has a different definition of "size", so that seems wrong. But I argue that the "ls" option is called "--size", so there's a conflict already and qemu-img info is not the first tool to disagree with stat on this.
I think if you ask most users what is a file size they will tell you what stat is returning. If we use the term in the way most people expect we can make tools easier to use. Users of qemu-img have no way to tell what is disk-size, the value is not documented, at least not in the manual or online help. I think the easy way to improve this is to show both the "allocated size" (st_size * block_size), and the "file size" (st_size). Nir
Max
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4JgC3IunLbJ0G8fkgNsQeg3PIJ43XvNLO Content-Type: multipart/mixed; boundary="o3shsonQasX9drPhV9NfPorFSsboNCKwB"; protected-headers="v1" From: Max Reitz <mreitz@redhat.com> To: Nir Soffer <nsoffer@redhat.com> Cc: Gianluca Cecchi <gianluca.cecchi@gmail.com>, "qemu-block@nongnu.org" <qemu-block@nongnu.org>, Paolo Margara <paolo.margara@polito.it>, users <users@ovirt.org> Message-ID: <546b8b49-4523-3a55-6665-b7b2db85f7e6@redhat.com> Subject: Re: [Qemu-block] import thin provisioned disks with image upload References: <CAG2kNCy9Ok=rqbAi4i+XfWGoF=pSjugsAv=iP=whgf7QPtJVsA@mail.gmail.com> <CAMRbyyu4rchkT8WYE-QWwkFZFKGaKtFzoLPX1_jkwYDhNBn0Mg@mail.gmail.com> <5c36d206-1e28-9376-dd68-3675793af55f@redhat.com> <CAMRbyyt7P+Du1MS6q5FHzuyrBvMZhf5y2CRJ=Fa3dV_co5VBDw@mail.gmail.com> In-Reply-To: <CAMRbyyt7P+Du1MS6q5FHzuyrBvMZhf5y2CRJ=Fa3dV_co5VBDw@mail.gmail.com> --o3shsonQasX9drPhV9NfPorFSsboNCKwB Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2017-12-08 21:56, Nir Soffer wrote:
On Fri, Dec 8, 2017 at 5:23 PM Max Reitz <mreitz@redhat.com <mailto:mreitz@redhat.com>> wrote:
[...]
What "stat" reports as "size" I'd call the length (what qemu-img in=
fo
calls "virtual size" for raw images).=C2=A0=20 =20 =20 raw images are not an issue since the virtual size is the file size.
I personally don't quite see how the file length is important for other image types. At least the qcow2 driver doesn't really try to keep the file length small because it generally assumes that it's just a number that doesn't really matter. (That was my impression, at least.)
What I (and qemu-img info) call "size" is how much disk space is actually used.=C2=A0 And both ls -=
s and du
agree that it's 0 bytes in this case. =20 By the way, yes, "stat" has a different definition of "size", so th=
at
seems wrong.=C2=A0 But I argue that the "ls" option is called "--si=
ze", so
there's a conflict already and qemu-img info is not the first tool =
to
disagree with stat on this. =20 =20 I think if you ask most users what is a file size they will tell you wh=
at
stat is returning. If we use the term in the way most people expect we can make tools easier to use.
First of all, we cannot easily change the name from "size". In the QAPI definition of ImageInfo it's called "actual-size", so we cannot change it without breaking compatibility. We could change the human-readable output, though; maybe to something like "host disk usage".
Users of qemu-img have no way to tell what is disk-size, the value is not documented, at least not in the manual or online help.
Documentation is a different issue. There is some for the actual-size field of ImageInfo, but even that is indeed lacking.
I think the easy way to improve this is to show both the "allocated siz= e" (st_size * block_size), and the "file size" (st_size).
Not impossible, although I personally don't really see the point. To be honest, what I fear is that people see the file length and complain why it's so large when it's actually just some number that shouldn't matter whatsoever. If people really want to find out, I don't think ls -l is that hard to use. OK, so let me sum up: First, I agree that "file size" is confusing. (I disagree that it would be wrong. I think it is simply ambiguous.) So we should rename it at least in the human-readable output. Secondly, we should have documentation about this in the qemu-img man page, and better documentation for ImageInfo.actual-size. Thirdly, I don't see the point of displaying the file length in qemu-img info. But since you think it useful and it probably wouldn't be too hard, we can add it. My only fear about this is that I consider it an arbitrary and useless number that may confuse people. It hopefully shouldn't, as long as they can see the actual disk usage at the same time, though. (I just don't know how seeing the actual image file length in qemu-img info would have helped in your case. The important thing would have been to know that image files usually do contain large holes and you need to enable hole detection when transferring image files anywhere (as far as I have seen).) Max --o3shsonQasX9drPhV9NfPorFSsboNCKwB-- --4JgC3IunLbJ0G8fkgNsQeg3PIJ43XvNLO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQFGBAEBCAAwFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAlouuV4SHG1yZWl0ekBy ZWRoYXQuY29tAAoJEPQH2wBh1c9AFcQIAKxvRI8Xq4PTY0qZodROxE4oNNbRTRYo PF69lVtQtY11BpXbGN0Wayk9cglbXuk3Xul3f1efw1k/TGOdsgz6HdYHGtfPjnAs ZSTYE+mOtMoAZ84JU+3E9RFDwY5FdkHBW4dzgBqd3EU0YMjxLEQp3Q8TbxggCgPe +3G9lK5YlHw+g4XPe7zDowUZY9gD81Z9sAo+GXDcJ6ZkBPUUQfh8e2xrThR9nPOP 5jaV3EquuydQRGrVcQiBS01simHxHwthOTd7lQqh2IA0Jkj7q6U6a2RIces0IL9L 8D9//2n1dunZUZQ4uTvyMHDsDqUZLhARnSVcq5BUT5OUczy2ywRrkmA= =xpmr -----END PGP SIGNATURE----- --4JgC3IunLbJ0G8fkgNsQeg3PIJ43XvNLO--
participants (4)
-
Eric Blake -
Gianluca Cecchi -
Max Reitz -
Nir Soffer