qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-img: Saner printing of large


From: Daniel P . Berrangé
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH] qemu-img: Saner printing of large file sizes
Date: Mon, 1 Apr 2019 14:16:41 +0100
User-agent: Mutt/1.11.3 (2019-02-01)

On Mon, Apr 01, 2019 at 03:04:16PM +0200, Kevin Wolf wrote:
> Am 30.03.2019 um 16:07 hat Eric Blake geschrieben:
> > Disk sizes close to INT64_MAX cause overflow, for some pretty
> > ridiculous output:
> > 
> >   $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd'
> >   image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket
> >   file format: raw
> >   virtual size: -8388607T (9223372036854775296 bytes)
> >   disk size: unavailable
> > 
> > But there's no reason to have two separate implementations of integer
> > to human-readable abbreviation, where one has overflow and stops at
> > 'T', while the other avoids overflow and goes all the way to 'E'. With
> > this patch, the output now claims 8EiB instead of -8388607T, which
> > really is the correct rounding of largest file size supported by qemu
> > (we could go 511 bytes larger if we used byte-accurate sizing instead
> > of rounding up to the next sector boundary, but that wouldn't change
> > the human-readable result).
> > 
> > Reported-by: Richard W.M. Jones <address@hidden>
> > Signed-off-by: Eric Blake <address@hidden>
> 
> This is quite obviously a bug fix for some cases. This suggests that we
> want it in 4.0.
> 
> It is also an output change for other cases, like going from "8M" to
> "8 MiB". We probably can't tell for sure whether some tools expect the
> spelling "8M" (even if this is supposed to be the human interface and
> tools should be using JSON) or feed the change back to qemu-img or
> qemu-io (which accept "8M", but not "8 MiB" as sizes in most places).
> This suggests that we shouldn't make this change as late as -rc2.

If it breaks our own tests, then it is possible to break other tools
too.

> So what is the conclusion?

The safe option is to do the minimal fix for the existing code and look at
the refactoring in the next dev cycle.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]