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

[Bernhard Fischer]

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:
>https://lists.oetiker.ch/pipermail/rrd-developers/2007-May/001869.html

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
  lazy..

These two could go hand in hand, obviously.

cheers,
Bernhard