Coda File System

Re: crash in rvmlib_free (not necessarily) during repair

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Wed, 10 Jul 2013 07:17:59 -0400
On Wed, Jul 10, 2013 at 10:30:14AM +0000, u-codalist-rcma_at_aetey.se wrote:
> On Wed, Jul 10, 2013 at 11:53:31AM +0200, Piotr Isajew wrote:
> > Is it possible, that 64-bit machine won't be compatible with
> > 32-bit one for server?
> 
> I would expect then to be incompatible. I did not look at the relevant
> code but according to old posts from Jan the format of the log data
> between the servers correspponds to the internal representations, which
> would/might differ for different endians or different word length.

The misinformation is strong in this whole thread, not really sure where
to start.

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.

Jan
Received on 2013-07-10 07:18:56