[rrd-developers] [PATCH,RFC] optional mmap based file I/O

Bernhard Fischer rep.dot.nop at gmail.com
Thu May 24 18:02:20 CEST 2007

On Thu, May 24, 2007 at 05:46:12PM +0200, Bernhard Fischer wrote:

>>I still see implicit decls of chroot and (from rrd_graph.c) implicit
>>decls of localtime_r and tzset, fwiw.
>Then there are those redefinitions when building the perl wrapper.
>I take it that we cannot simply use the CC that was given by the user to
>build the perl module, right?
>If we have to use the perl-given CC, then we have to re-check all our
>options against the perl CC, which may or may not result in inconsistent
>builds as far as the wrapper versus the real rrdtool is concerned.
>Therefor, i suggest to build the perl wrapper with the CC which we used
>to build rrdtool. Opinions?
>For the most part, the changes are now done¹) (checked FD-based vs. mmap
>based vs. vanilla 1.2.23-mmap for 'last', 'fetch' and 'dump'), from my
>POV. This means that the fine-tuning can start (finally, yay! :).
>Does somebody have a sequence of creating a dummy rrd, and (manually!)
>doing rrd_update()s on it, by chance?

This is the most important thing which is still outstanding. Sit down and
make rrd_update as fast as possible.

The fadvise approach (against 1.0.49 (!) which sounds a little bit odd
to me ;) is nice and all, but we should be able to do better than that.

>¹) One thing that i still want to repair is the "librrd vs. rrd.h --
>incomplete interface", as described here:

Some additional, random TODOs:
- janitorial cleanups
  There is quite some opportunity for janitorial code-cleanups, IMO.
  Error pathes come to mind.

- have to use rrd_close (which should call rrd_free()) everywhere.
  This is currently not done at all (we let the kernel do the cleanup
  for now, but this will have to be done properly anyway) as i was too

These two could go hand in hand, obviously.


More information about the rrd-developers mailing list