On Tue, Jan 18, 2005 at 09:19:30AM +0100, Oliver Eichler wrote:
> I try to find a replacement for NFS on our network, thus evaluating Coda. I 
> have problems compiling coda on a AMD64 Linux (SuSE 9.2) system. compiling 
> lwp will give me

Yeah, we're don't yet compile correctly on 64-bit. I already went
through LWP and RVM and they worked fine on a DEC Alpha machine (and
possibly sparc64).

> gcc -g -O2 -o .libs/cswitch cswitch.o  ./.libs/liblwp.so -Wl,--rpath 
> -Wl,/usr/lib64/
> ./.libs/liblwp.so: undefined reference to `returnto'
> ./.libs/liblwp.so: undefined reference to `savecontext'

LWP depends on a tiny bit of assembly for each CPU, I don't think anyone
has ever written the bit needed for AMD64. In the LWP source tree there
is a little 'PORTING' document that contains some notes on what the main
obstacles are.

I'm assuming that the x86_64 assembly is fairly similar to the i386
assembly. Some of the numbers probably have to be changed a bit.

Here is a stab at what might be needed,

    #include <linux/linkage.h>

    #define f 72     /* assuming same number of registers as i386, but
		        that they are 64-bits, so I doubled the value. */
    #define area1 80 /* all arguments are pointers, so I keep adding 8 */
    #define newsp 88
    #define topstack 0

	.text
    ENTRY(savecontext)
	pusha			   /* save all registers on the stack */
	movl  area1(%esp), %eax	   /* get ptr to save area */
	movl  %esp, topstack(%eax) /* save stackptr in save area */
	movl  f(%esp), %eax	   /* get ptr to function 'f' */
	movl  newsp(%esp), %ecx	   /* get ptr to new stack */
	cmpl  $0, %ecx		   /* check if zero */
	je    L1		   /* use old stack if new stack ptr is 0 */
	movl  %ecx, %esp	   /* move new stack into place */
    L1:
	xorl  %ebp, %ebp	   /* clear stackframe */
	call  *%eax		   /* call into function 'f' */

	movl  $0, 0		   /* we should never get here, so this
				      triggers a segfault */

    #define area2 8

    ENTRY(returnto)
	movl  area2(%esp), %edx	   /* get ptr to save area */
	movl  topstack(%edx), %esp /* restore stack pointer */
	popa			   /* pull all saved registers */
	ret			   /* return to calling function */

> I searched the mail archive for AMD64 and noticed that Coda has some problems 
> getting ported to 64bit systems (January 2004). Is this still an issue?

Yeah, once you get LWP running, most of the rest will probably compile
but it won't be compatible on the wire with 32-bit architectures.

> As we do have a mixed network with Windows and Linux clients I need a Windows 
> 2000/Xp client. The news says something about comming soon (October 2004). 
> What is 'soon' :)

Don't really know, I'd say the code is getting pretty usable by now
(i.e. it doesn't blue screen the machine whenever the userspace daemon
hickups). I guess there is still some clean up needed.

> * Encryption and Passwords: Coda does not encrypt data. Password
>   encryption is weak. Is this right?

Correct to a point, the rpc2/sftp protocol can actually encrypt all
data, but at the moment that encryption would be as weak as the existing
password encryption (XOR), and it makes debugging from sniffed network
traffic a lot harder. So since it doesn't really add any security and
hinders debugging I don't think it is enabled.

> * Making backups (cloning) is easy as there are scripts. Restoring a
>   backup is bad documented and far from trivial. Still true?

Well, I've moved away from using those scripts and am using a slightly
modified amanda setup (added CODA and CODATAR dumptypes). The CODA
dumptype still dumps Coda volume dumps which need to be restored to a
running server (and then copied from the restored readonly volume to a
readwrite replicated volume). The CODATAR dumptype feeds the dumps
through codadump2tar and created normal tar archives. Those can be
easily extracted, don't need a running server, but they do miss some
information that is present in the normal volume dumps like ACL's and
such.

> * What happens if the database gets corrupted? Are there any redundancy 
> concepts? Does the server check database integrity cyclic and does it send 
> warnings? 

Database? I guess you mean RVM, where we store the metadata. There are
some checks during startup to see if every file has a data container,
and if all files listed in a directory actually exist and such. Some of
these checks fix up small problems, in other cases when we aren't sure
how to fix the problem we actually kill the server to prevent the
corruption from spreading to other replicas. We only perform the salvage
check during startup. It is possible to trigger the check while the
server is running, but the last time I tried it started deleting random
files from other volumes on the same disk, I guess the salvager decided
that those files weren't used.

Now if there are other replicas available and a server is totally hosed,
it is possible to completely reinstall the server from scratch,
recreated empty volume replicas and have server-server resolution
repopulate the server.

Jan