endianness issues on volume dumps

[Neil Horman-2]

Hey all-
        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
any of this, but I tried to restore a dump the other day, and it failed.  The
error message it gave, when I looked through the source, indicated that one of
the magic values at the dump header was incorrect.  Looking at it, it appeared
to be backwards.  Anywho, thought I'd ask around quick before I went digging
into it any more.

Thanks
Neil

[Jan Harkes]

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

[Greg Troxel]

Jan Harkes <jaharkes@...> writes:

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

It would be good to convert to uint32_t and verify no regressions on
i386, just for cleanliness.  The PDP-11 coda port is going to run into
trouble on this point, since after all int is 16 bits there.  Of course
they have a long way to do before the backup format is the biggest
problem.  My NetBSD/alpha machine is powered off, but I dimly remember
int being 64 bits there.

[u+codalist-wk5r]

Hi Greg,

On Fri, Feb 06, 2009 at 08:29:02AM -0500, Greg Troxel wrote:
> i386, just for cleanliness.  The PDP-11 coda port is going to run into
> trouble on this point, since after all int is 16 bits there.  Of course

Do you mean the port to 2.11BSD which you worked on back in 2004?
I guess it is tricky to compile Coda on such ancient systems
and hence even harder to keep it up to date? What is its status today?
It's amazing to be able to access Coda even on 16-bit systems.

Regards,
Rune