Negative values for disk read and write values in log file about dstat HOT 6 CLOSED

Could you please try to reproduce using the master branch ? A lot of fixes went into Dstat since our 0.7.2 release.

Also, negative values are normal, that's most likely cause by counter rollovers. See the documentation related to it.

from dstat.

Sorry, but won't be able to do that because of lacking the time right now. I might get back to this issue a couple of weeks later.

Anyway, thanks for your quick respond on this. And thank you for this great tool.

You think it would give proper results if I always took the absolute values of the numbers?

from dstat.

I have also experienced this bug. While using dstat and the similar tool ifstat, I have witnessed some strange behaviour. At corresponding times, ifstat will suddenly log 0 B/s, while dstat logs a massively negative number, in my case -4282662640 B/s, while the surrounding measurements produce a median value of 12304656.0 B/s. Curiously, I found that if 2^32 is added to this negative result, we get the number 12304652.0, which would be an acceptable value.

As this behaviour coorelates with the zero returns in iperf (another oddity that should never happen in this context), I suspect that the source of data for these methods may be to blame. In either case, I hope that this helps you to fix this issue. While I accidentally overwrote the logs and plots that showed this error, I will be sure to append them if I see it happen again.

from dstat.

These are counter-rollovers. Please read the documentation related to counter-rollovers.
This is less likely to occur on 64bit systems, but common on high-speed interfaces on 32bit systems.

from dstat.

@dagwieers do we not compensate for counter rollovers? I've done it before, it's not that hard:

https://github.com/scottchiefbaker/perl-snmp-monitor/blob/master/snmp_int_watch.pl#L373

from dstat.

We don't. Theoretically with bonded 10Gbit interfaces you can have rollovers every few seconds. So if you have a larger window you can have multiple rollovers in a single time-frame. So if you start compensating, you hide this information with no guarantee or certainty, while if you leave that information in place it is up to the end-user to see how to process this information (either compensate or deem compensation impossible).

I would agree if you can do it correctly in 100% of the cases, but since we cannot be sure, I'd rather not. Besides thanks to 64bit counters this problem is dealt with properly on newer systems.

And that's why we have it documented.

from dstat.