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--