Coda File System

Re: endianness issues on volume dumps

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Wed, 4 Feb 2009 12:32:36 -0500
On Sat, Jan 31, 2009 at 09:37:38AM -0500, Neil Horman wrote:
> 	Has anyone seen any issues with dumps created by the coda backup utility
> result in dump files that have some reverse endian fields in their headers?  I'm
> backing up volumes on an x86_64 machine using an x86 system, so I didn't expect

I wouldn't expect endian issues, but I guess alignment issues are
possible. Coda has started to support 64-bit not that long ago, and all
of my servers are still 32-bit machines so it doesn't surprise me too
much that there may still be some unresolved issues.

It looks like dumpstuff.cc (where the dumped data is written/formatted)
uses a hand-coded version of htonl.

    #define putlong(p, v) \
	*p++ =(unsigned char)(v>>24); *p++ = (unsigned char)(v>>16); \
	*p++ = (unsigned char)(v>>8); *p++ = (unsigned char)(v);

It looks to me like the dump pretty much assumes 32-bits and stores
everything in big-endian order. I looked at both dumpstuff and readstuff
and didn't see any obvious endian or 64-bit issues. Well everything uses
unsigned int instead of uint32_t, but I'm pretty sure that really
shouldn't make a difference on x86_84 or amd64 machines, I think
something like that may have only mattered on alpha.

Jan
Received on 2009-02-04 12:33:36