[rrd-developers] rrd file access code

[Tobias Oetiker]

Hi Daniel,
> Yes, the RRA pointers.
>
> I think I've found your randomisation code in rrd_create.c (the call to
> rra_random_row())
>
> Here is what I would like to do:
>
> - rrd_create will not call rra_random_row() directly - there will need
> to be a method in rrd_open.c, perhaps call it rra_select_initial_row()
>
> - There will be a default implementation of rra_select_initial_row(),
> based on your code
>
> - Each time rrd_update() is invoked, it will call a method in
> rrd_open.c, perhaps call it rra_notify_current_row()
>
> - The filesystem backend may choose to store the most recent value from
> rra_notify_current_row(), and use that to help decide what value to
> return for calls to rra_select_initial_row()
>
> - For tighter synchronisation, it would be nice to have the pointer left
> un-initialised in rrd_create().  The pointer should be initialised on
> the first call to rrd_update().
>
> You are quite right about the disk block issue - however, in my striping
> situation, all the RRAs (potentially thousands of them) will be striped
> over the same disk blocks, so the disk blocks representing the current
> row will be served by cache hits on read and write.
>
> I notice that the mmap code is quite tightly integrated.  Do you see
> that becoming a run-time option?  It would be useful to be able to
> select between regular file IO, mmap or some other custom implementation
> at run-time.

having things configurable at runtime is certainly a 'good thing'
in todays world where skills in compiling stuff are rapidely
dwindling ...

As abstractions go ... having the ability to transparently support
different storage layouts is also something that will be required
for the new rrd format if there is to be backward compatibility.

cheers
tobi


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