[rrd-developers] Architecture-dependent RRD file format

[Matt Zimmerman]

I received the following bug report from a fellow Debian developer.  We
are using RRDtool in the Debian system environment, which is very
architecturally diverse, and the fact that RRDs are not portable across
architectures is making things more difficult.

I am wondering if there are any plans to address this issue in future
RRDDtool development, and if someone could clarify the reasons for the
architecture-independence.  Am I correct in thinking that it has to do
with floating-point storage formats?  From looking at the code, C struct
padding/alignment issues could enter into it as well.

Please preserve Cc: 117142-forwarded at bugs.debian.org in followups.

----- Forwarded message from Martin Schulze <joey at finlandia.infodrom.north.de> -----

Date: Fri, 26 Oct 2001 19:22:48 +0200
From: Martin Schulze <joey at finlandia.infodrom.north.de>
To: Matt Zimmerman <mdz at debian.org>
Cc: 117142 at bugs.debian.org
Subject: Re: Bug#117142: arch-dependency on RRDs

Matt Zimmerman wrote:
> On Fri, Oct 26, 2001 at 09:40:54AM +0200, Martin Schulze wrote:
> 
> > Package: rrdtool
> > Version: 1.0.33-5
> > 
> > ERROR: This RRD was created on other architecture
> > 
> > This is very annoying, since our main archive server is a sparc64
> > and the non-US machine is a simple i386, so RRD's from both machines
> > cannot be combined.  Even worse, since auric is stable it lacks the
> > unstable rrdtool so things will have to be graphed on a different
> > machine.
> > 
> > A fix is *highly* appreciated.
> 
> What upstream usually recommends is to dump the RRD to XML (rrdtool
> dump) and import it back (rrdtool restore).  This is a pain, but it is
> easy to automate.

That's what I do now... It's very, very silly:

rrd update on auric
rrd dump on auric

transfer to caballero

rrd restore on caballero
rrd graph on caballero

transfer graphics to pre-final destination on master

transfer to final destination

> I believe the difficulty lies in the lack of standardization for storage
> of floating-point values.  I will find out what is happening in the
> 1.3.x development tree with this issue.

Thanks

Regards,

	Joey

-- 
Experience is something you don't get until just after you need it.

Please always Cc to me when replying to me on the lists.

----- End forwarded message -----

-- 
 - mdz

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