On Thu, Jan 14, 2010 at 10:27 AM, Florian Forster <[email protected]> wrote: > Hi Mark, > > On Thu, Jan 14, 2010 at 10:41:10AM +0100, Florian Forster wrote: >> Yeah, sounds like an unsigned 32bit integer being cast to a signed one. > > turns out the data was first stored in a long (32bit / 64bit, depending > on architecture), then a counter_t (unsigned 64bit) then cast to a > derive_t (signed 64bit). > > I've changed this to use `derive_t' thorough the entire plugin. Not sure > if this fixes the problem's core, though: It seems like you're > missing all negative "counter" values. [*] > > After taking a good look at the RRDtool sources it turns out that there > have been a number of incarnations of this bug over the year. The > symptoms change over the time, and one of those is that values with > leading hyphens are dismissed as incorrect. I've sent a patch fixing all > the problems I could think of to the RRDtool mailing list and it's been > applied already. [0] > > Regards, > -octo > > [*] Though you'll need to write 2^63-1 bytes (roughly 9.2 Exabytes) for > this, assuming Linux provides 64bit counters. > [0] <http://oss.oetiker.ch/rrdtool-trac/changeset/2001/trunk/program/src>
Wow, that was quick sleuthing! Sounds excellent, thanks for taking care of it so quickly. Is there anything you'd like me to test for the counter->derive_t change? To answer your question in the previous email about librrd version, the box I originally compiled on got accidentally upgraded (no joke) from Etch to Lenny so I don't have the exact version from compile-time, but the library being pulled in at runtime is librrd_th.so.2.0.8, which is the lib from Etch's librrd2 package. That's quite likely the exact version it was compiled against, since I don't see a newer version in etch-backports. _______________________________________________ collectd mailing list [email protected] http://mailman.verplant.org/listinfo/collectd
