[Libguestfs] [PATCH nbdkit 1/3] filters: stats: Show size in GiB, rate in MiB/s

Nir Soffer nsoffer at redhat.com
Sat Nov 30 14:37:24 UTC 2019


On Sat, Nov 30, 2019 at 8:58 AM Richard W.M. Jones <rjones at redhat.com> wrote:
>
> On Sat, Nov 30, 2019 at 02:17:05AM +0200, Nir Soffer wrote:
> > I find bytes and bits-per-second unhelpful and hard to parse. Using GiB
> > for sizes works for common disk images, and MiB/s works for common
> > storage throughput.
> >
> > Here is an example run with this change:
> >
> > $ ./nbdkit --foreground \
> >     --unix /tmp/nbd.sock \
> >     --exportname '' \
> >     --filter stats \
> >     file file=/var/tmp/dst.img \
> >     statsfile=/dev/stderr \
> >     --run 'qemu-img convert -p -n -f raw -O raw -T none /var/tmp/fedora-30.img nbd:unix:/tmp/nbd.sock'
> >     (100.00/100%)
> > elapsed time: 2.313 s
> > write: 1271 ops, 1.14 GiB, 502.63 MiB/s
> > zero: 1027 ops, 4.86 GiB, 2153.24 MiB/s
> > extents: 1 ops, 2.00 GiB, 885.29 MiB/s
> > ---
> >  filters/stats/stats.c | 34 +++++++++++++++++++---------------
> >  1 file changed, 19 insertions(+), 15 deletions(-)
> >
> > diff --git a/filters/stats/stats.c b/filters/stats/stats.c
> > index 98282e2..45bedae 100644
> > --- a/filters/stats/stats.c
> > +++ b/filters/stats/stats.c
> > @@ -49,6 +49,10 @@
> >  #include "cleanup.h"
> >  #include "tvdiff.h"
> >
> > +#define MiB 1048576.0
> > +#define GiB 1073741824.0
> > +#define USEC 1000000.0
> > +
> >  static char *filename;
> >  static bool append;
> >  static FILE *fp;
> > @@ -64,34 +68,34 @@ static uint64_t extents_ops, extents_bytes;
> >  static uint64_t cache_ops, cache_bytes;
> >
> >  static inline double
> > -calc_bps (uint64_t bytes, int64_t usecs)
> > +calc_mibps (uint64_t bytes, int64_t usecs)
> >  {
> > -  return 8.0 * bytes / usecs * 1000000.;
> > +  return bytes / MiB / usecs * USEC;
> >  }
>
> The idea isn't bad, but I think we can lose data doing this.  What
> happens if the rate is substantially less than 1 megabit?

Do you mean values less than 0.01 GiB, or 0.01 MiB/s? This does not
look like interesting use case to me. We can use .3f format to avoid
losing data in such cases.

> We either ought to scale this according to the size of the number
> being printed, or else let the user select it.

It is better to scale the unit based on the size, using the same
way ls -lh does it, but I don't have time to work on this now.

> For scaling, here's
> some code from fio:
>
> https://github.com/axboe/fio/blob/bef74db41fb5a1607fd55cb86544165fc08acac1/lib/num2str.c#L72
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
>





More information about the Libguestfs mailing list