On Wed, Jul 10, 2013 at 08:01:00AM -0400, Greg Troxel wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> > There is no such representation problem as far a I know. RPC2 has always
> > properly converted to and from network byte order. There are some
> > packets sent as 'binary blob', such as the reintegration log, the
> > directory contents (which is exchanged during server resolution) and the
> > repair fix files.
> >
> > Reintegration log is 'endian-corrected' by feeding it through the
> > MultiRPC2 marshalling code. Directory data has 3 or 4 different
> > representations, on-disk, in-memory, on-the-wire, and kernel-native,
> > and has it's limitations (size/# of directory entries). The repair fix
> > files are in a 'human readable' format and parsed by the server, either
> > way there are no endianness or 32/64 issues there.
> >
> > Just about everything in Coda is based on 32-bit integers even when you
> > are running on a 64-bit systems, so 64-bits really just gives you more
> > addressible memory.
> 
> So have you run across i386 and sparc64 servers, or something like that,
> and seen the test suite :-) pass?   I can't quite tell if you mean
> 'should work' vs 'has been tested and is known to work'.

That would be a should work, I've used mixed 32 and 64 bit servers in a
single replicated group as well as a combination of big endian clients
with little endian servers.  Haven't actually used big and little endian
servers in the same replication group but it really should 'just work'.

The main thing is that Coda uses mostly 32-bit integers even on a 64-bit
system, it is really just the (local) memory addressing (pointers and
RVM) that are different.

The big vs. little endian is something that I've really mostly tested
between clients and servers. The servers tend to be bought in batches so
you end up with pretty much identical machines, but clients are
typically  more mixed.

Jan