[rrd-developers] Update ex post?
sh at tokkee.org
Mon Aug 23 23:13:32 CEST 2010
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
> 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
* 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
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