Re: [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



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [Qemu-block] Scheduling daily Snapshot

[Max Reitz]

On 2017-12-07 23:19, Nir Soffer wrote:
> On Wed, Dec 6, 2017 at 6:02 PM Jason Lelievre  > wrote:
> 
> Hello,
> 
> What is the best way to set up a daily live snapshot for all VM, and
> have the possibility to recover, for example, a specific VM to a
> specific day?
> 
> 
> Each snapshot you create make reads and writes slower, as qemu has to
> lookup data through the entire chain.
> 
> When we take a snapshot, we create a new file (or block device) and make
> the new file the active layer of the chain.

I'm not sure how much this is going to slow you down exactly, but I can
tell you that there are also incremental backups to look into.

(e.g. https://wiki.qemu.org/Features/IncrementalBackup)

Max



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [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  <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