On 2017-12-08 21:56, Nir Soffer wrote: > On Fri, Dec 8, 2017 at 5:23 PM Max Reitz <mre...@redhat.com > <mailto:mre...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users