[rrd-developers] Update ex post?

Sebastian Harl sh at tokkee.org
Mon Aug 23 23:13:32 CEST 2010

Hi Till,

On Mon, Aug 23, 2010 at 07:40:01PM +0200, Till Dörges wrote:
> I know that RRDtool doesn't support updates ex post and that this is
> by design. I've looked around a bit and didn't manage to find a more a
> detailed reasoning as to why this is so. So I'd be very curious about
> pointers or hints.

Roughly, the following happens when doing an UPDATE:

 * The data is fed into the preparation area for a new PDP (primary data
   point). That preparation area basically includes information required
   to build the next PDP.

 * If the PDP is finished (i.e., after one step/interval), the PDP is
   fed into the preparation area for each RRA. This basically is an
   staging area for the next CDP (consolidated data point) and contains
   information required to build that CDP.

 * If the CDP is finished (i.e., after enough PDPs (which may be
   "UNKNOWN" in case no UPDATES came in) have accumulated), it is
   actually written to the RRA and the RRA preparation area is used for
   the next CDP. I.e., all information how to recreate the CDP is lost
   (which basically is the main point why consolidation happens ;-)).

In order to modify some past value, you'd have to recreate all CDPs
affected by that change. For that, you'd basically need all PDPs that
made up that CDP, since (in general) you don't know the old value (the
one that's supposed to be modified) and, thus, you don't know how
changing that value affects the CDP (well, unless you accept rather
vague approximations).

> I'm wondering how much effort would it take to extend RRDtool to
> provide such a feature?

So, I don't see any reasonable way to solve that with the current
architecture (and I don't see any way how this should be improved).
There are two ways that could be *implemented* with rather low effort
but I don't think that any of those would make much sense. Anyway, those

 * Provide a "replace" function, whose arguments would be a time-stamp,
   the old and the new value. That should make it possible to recalcu-
   late old CDPs (I guess). I don't see any reasonable use case for
   that, though.

 * Provide some function that would accept a new value for each and
   every RRA affected by a given time-stamp. Fairly stupid as well, imho

So, I'm sorry, but unless somebody comes up with a nice solution that
did not come to my mind, I suppose that this feature will never exist.


Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20100823/34c91f08/attachment.pgp 

More information about the rrd-developers mailing list