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

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