Re: [ovirt-users] [Qemu-block] import thin provisioned disks with image upload

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(a)redhat.com&gt; To: Nir Soffer <nsoffer(a)redhat.com&gt; Cc: Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt;, &quot;qemu-block(a)nongnu.org&quot; <qemu-block(a)nongnu.org&gt;, Paolo Margara <paolo.margara(a)polito.it&gt;, users <users(a)ovirt.org&gt; Message-ID: <546b8b49-4523-3a55-6665-b7b2db85f7e6(a)redhat.com&gt; Subject: Re: [Qemu-block] import thin provisioned disks with image upload References: <CAG2kNCy9Ok=rqbAi4i+XfWGoF=pSjugsAv=iP=whgf7QPtJVsA(a)mail.gmail.com&gt; <CAMRbyyu4rchkT8WYE-QWwkFZFKGaKtFzoLPX1_jkwYDhNBn0Mg(a)mail.gmail.com&gt; <5c36d206-1e28-9376-dd68-3675793af55f(a)redhat.com&gt; <CAMRbyyt7P+Du1MS6q5FHzuyrBvMZhf5y2CRJ=Fa3dV_co5VBDw(a)mail.gmail.com&gt; In-Reply-To: <CAMRbyyt7P+Du1MS6q5FHzuyrBvMZhf5y2CRJ=Fa3dV_co5VBDw(a)mail.gmail.com&gt; --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: [...] fo 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.) s and du at ze", so to at 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". Documentation is a different issue. There is some for the actual-size field of ImageInfo, but even that is indeed lacking. e" 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" --4JgC3IunLbJ0G8fkgNsQeg3PIJ43XvNLO--