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

[Max Reitz]

On 2017-12-08 21:56, Nir Soffer wrote:
> On Fri, Dec 8, 2017 at 5:23 PM Max Reitz <mreitz at redhat.com
> <mailto:mreitz at redhat.com>> wrote:

[...]

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

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

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 size"
> (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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/users/attachments/20171211/9d0341ff/attachment.sig>