Coda File System

Re: coda endian problems??

From: Troy Benjegerdes <hozer_at_hozed.org>
Date: Wed, 14 Jul 2004 12:21:37 -0500
On Wed, Jul 14, 2004 at 12:08:36PM -0400, Jan Harkes wrote:
> On Wed, Jul 14, 2004 at 09:49:38AM -0400, Greg Troxel wrote:
> >   as far as I recall, Coda servers are endian-dependent, in the sence that
> >   you cannot mix different-endianness servers in the same volume replication
> >   group. May be it is still possible to use them in the same realm,
> >   while avoiding volume replication between them.
> > 
> >   (Servers send log information to each other, and it is pretty much in its
> >   internal representation)
> > 
> > Wow - I had no idea!  Thanks - and I'll be careful when I start up
> > sparc servers.
> 
> I'm not entirely sure whether it would work or not. There seems to be
> marshalling related code in coda-src/resolution/, but that might just be
> related to moving data in and out of RVM.
> 
> Jan

It sorta works.. until you get into any sort of disconnected mode.

So far, I have managed to sig11 venus on both ppc and x86, but I'm doing
a lot better than the last time I tried coda since I haven't killed a
server or corrupted the filestore yet ;)

The lastest crash on the x86 venus occured after messing around in a
directory from the ppc client and having the ppc client fall over.

The last backtrace let me to believe some RPC2 thing wasn't endian-safe,
but this makes me not so sure. Any ideas?

(gdb) bt
#0  0x4017c116 in sigsuspend () from /lib/tls/libc.so.6
#1  0x080c8738 in SigChoke (sig=354089116) at sighand.cc:241
#2  <signal handler called>
#3  0x0807509e in fsobj::Open (this=0x50a36d08, writep=0, execp=0,truncp=0,
    cp=0x151b1e18, uid=1000) at fso.h:686
#4  0x080c1018 in vproc::open (this=0x8390c48, cp=0x151b1e18,flags=1352887560)
    at vproc_vfscalls.cc:223
#5  0x080c6f03 in worker::main (this=0x8390c48) at worker.cc:1327
#6  0x080bb516 in VprocPreamble (init_lock=0x0) at vproc.cc:146
#7  0x40056476 in Create_Process_Part2 () at lwp.c:796
#8  0x40057303 in L1 () at process.S:455

	
Received on 2004-07-14 13:23:30