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

[Max Reitz]

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

Because I still think it's ambiguous.

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

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/20171208/bea8cbdb/attachment.sig>