[rrd-developers] Re: rrd format change ?

[Jake Brutlag]

> so if we can find a format for rrd which is better to accomodate
> future changes, I think it would be  worth while doing the changes
> now, and find a way to keep on reading old rrd files instead of
> adding more hacks and going to a better ormat later having evben
> more difficulty supporting old stuff ?

Okay, so if we are going do this, I think the first step is to abstract
the RRD header from the rest of code. The core files, such as
rrd_update, rrd_create, etc make extensive use of the internal structure
of the header. If the header was encapsulated and only accessed by a set
of accessor functions (obviously I'm thinking in C++, but this is doable
in C), the the other files need not be aware of the format on disk of
the header. The header format can change and the other files (update,
create, dump, restore, info, etc) remain unchanged. This encapsulation
would also confine changes to support different file versions to the
code for processing the header (well, as long as the only the header
changed for different versions).

For example, here is a current code block from rrd_update.c:

        for (i=0;i<rrd.stat_head->ds_cnt;i++) {
        if(isnan(pdp_new[i]))
            rrd.pdp_prep[i].scratch[PDP_unkn_sec_cnt].u_cnt += interval;
        else
            rrd.pdp_prep[i].scratch[PDP_val].u_val+= pdp_new[i];
	  }

This could read:

        for (i=0 ; i < getDSCount(&rrd) ;i++) {
        if(isnan(pdp_new[i])) {
            temp = getPDPParam(&rrd, i, PDP_unkn_sec_cnt);
            temp.u_cnt += interval; 
            setPDPParam(&rrd, i, PDP_unkn_sec_cnt, temp);
        } else {
            temp = getPDPParam(&rrd, i, PDP_val);
            temp.u_val += pdp_new[i]; 
            setPDPParam(&rrd, i, PDP_val, temp);
        }
	  }

Once implemented, these accessor functions could be even exposed through
the Perl interface, which would provide better, but controlled, access
for client programs to the header information. Of course, the downside
of this approach is a slight loss of efficiency.

Now if we buy into this approach, I can't volunteer to do everything
myself, but I am willing to commit to revising rrd_update.c and rrd_hw.c
once a set of accessor functions is decided upon and implemented.
rrd_update.c is a complicated module but I've spent a fair bit of time
working with it. rrd_update would definitely require an accessor
function for retrieving the size of header entries so that the pointer
file ptr arithmetic is does can be preserved.

Jake

Jake Brutlag
Network Analyst
Microsoft WebTV 

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi