[rrd-users] Architecture independence for rrd files

[Jean-Yves Avenard]

Hi

thanks for answering

On 21 January 2013 08:59, Steve Shipway <s.shipway at auckland.ac.nz> wrote:
> Making it arch-independent is not so easy (else it would have been done long ago as this has been on the cards some time).  There are several problems relating to the generated C struct which is written to the file as created in memory:
>
> 1. endian - is it MSB first or LSB first (or middle byte first as in windows)
> 2. 23/64 bit - how big is an integer?  This adjusts the size of the struct
> 3. alignment - does your architecture demand integers be byte-aligned and therefore generate padding bytes?
> 4. compiler peculiarities - some just do it differently at compile time.

To be honest, I can't see why any of what you have mentioned above are
an issue. That is if it was catered for right at the beginning.
Putting a layer between storage and working data is rather common
practice to prevent exactly that type of problem.

Things like how big is an integer, is rather irrelevant if you use
integer types that are well defined (eg. int16_t, in32_t, in64_t vs
plain int)
Alignment is only an issue at runtime, not storage.

As for compiler peculiarities, I have a problem figuring what they could be ...
>
> The first is actively checked for by RRDTool (looking for different magic numbers in the header) and - I think - so is the second.  Although it knows about them, though, working around it without losing a lot of efficiency would be a big problem.
>
> It might be better to create a program to convert RRD files in one go (we can already do an XML export/import of course) though this too could be more trouble than it is worth.

>
> I think there is more discussion on this in the Github area Tobi has set up https://github.com/oetiker/rrdtool-2.x

Not sure I'm willing to wait that long :)

I just want to do a quick resync of rrd files collecting on arm boxes
I have scattered around and display their content on a more beefy
server.

JY