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
Because I still think it's ambiguous.
$ qemu-img create -f raw empty 1G
Formatting 'empty', fmt=raw size=1073741824
$ qemu-img info empty
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 0
$ LANG=C stat empty
Size: 1073741824 Blocks: 0 IO Block: 4096 regular file
$ ls -s empty
$ du -h 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).