[rrd-developers] implementing portable format

Tobias Oetiker tobi at oetiker.ch
Sun Nov 2 08:42:31 CET 2008


Hi Kevin,

Yesterday kevin brintnall wrote:

> On Sat, Nov 01, 2008 at 09:33:46AM +0100, Tobias Oetiker wrote:
> > > Maybe we can start to tidy up for 1.4 now (while the storage code is
> > > relatively stable) and target the storage changes (portable format,
> > > different backends) for 1.5?
> >
> > yes you are right, this might be sensible ... release often,
> > release early ...
> >
> > what work do you see for the cached ?
>
> Here's what I'm currently pondering..  I'm interested in your thoughts on
> the new features...
>
> -----------------------------------------------------------------
>
> NEW FEATURES:
>
> * UPDATEV support?  It would require the daemon to keep a copy of the RRD
>   header of each file in memory, and perform the same calculations that
>   will ultimately be performed on the real file.
>
>   - higher memory utilization
>   - lots of disk reads when the working set is being "primed"
>   ? when an update causes a CDP to be written, does that require access to
>     the PDP rows or just the info in the header?
>   - If it does require reading the rows, the daemon can only efficiently
>     return the PDP updates (not CDP) during UPDATEV response

hmm, you will effectively reimplement the disk-cache ... to be able
todo the calculations you will have to keep everything except for
the RRA data space in memory ... you would have to change the rrd_update code
accordingly.

to me this looks more like a 1.5 feature (if at all) maybe with the
modified data access structure in 1.5, this could be implemented
much easier by hiding the header cache capability inside the
rrd_open code.

> * expose BATCH mode to API/bindings?
>   (for my setup I wrote my own protocol speaker and talk directly to the
>   daemon for high update rate)
>
>   + enables higher update rates
>   - client won't get return codes
>     (i.e. you can't know a FLUSH has completed while you're still in BATCH
>     mode).

yes this certainly makes sense, does rrd_update with multiple
arguments use the batch mode ?

> -----------------------------------------------------------------
>
> These are pretty straightforward...
>
> MISC:
>
> * memchr vs. strchr
>   + validate correct behavior if rrdcached receives a '\0' on input

ok
>
> * check strncpy() and snprintf() correct use of sizeof() bounds

ok
>
> * "quit" command (to close connection)

:-)
>
> * journal_write: pass sock, move "if(sock!=NULL)" logic into function

ok

cheers
tobi
>
> -----------------------------------------------------------------
>
> cheers,
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900



More information about the rrd-developers mailing list