Coda File System

Offline Cache went inconsistent

From: Steffen Neumann <sneumann_at_TechFak.Uni-Bielefeld.DE>
Date: 28 Nov 2003 11:20:27 +0100
Hi,

this is just a short mail (my defense is on monday)
to tell you that I have some problem with my venus.

To give you a brief idea what happend:

	1) I did a hoard walk on the 24th
	2) I went away and did plenty of hacking
	   on the presentation. 
	3) I *guess* that I exceeded the coda cache,
	   all of a sudden files had been thrown 
	   out of the cache. Luckily only yesterday 
	   evening.
	4) I came to my office, did a clog
	   and cfs lv /c/h/sneumann showed 
	   fully connected without anything pending.
	   Fine. I thought.

	5) clog on another client -> old content 
	   in files.

	6) Checking the laptop: Old date (24th) 
	   on the files, but new content.
	   CVS refused to check in.
	   (Yes, CVS directory was among those that timed out 
	    yesterday evening as well :-()

	6.5) touch * ; cvs commit helped the last problem.
	     And no, the files are still different 
	     on two fully connected machines.

	6.6) A touch * in a large directory (.../graphics)
	     killed venus, I will send the logs via private mail,
	     they're quite large.

	7) On the next startup venus discarded runt object
	   cdb-integration-de.dia and went on. Current files appeared 
	   on other clients.

No, this is not the kind of excitement I was looking for today.
Fortunately I am paranoid enough to have copies 
all over in /home and /tmp ;-)

So long,
Steffen


System(s) are: Laptop 2.4.2x, Coda 5.3.20-ish CVS,
Server 6.0.x. If needed I can send excerpts from server logs
on tuesday.

Hope this'll help in debugging:

#0  0x401a9c41 in __libc_nanosleep () at __libc_nanosleep:-1
#1  0x401a9b79 in __sleep (seconds=1) at ../sysdeps/unix/sysv/linux/sleep.c:70
#2  0x080cd62a in coda_assert (pred=0x80e15ab "0", 
    file=0x80d73e9 "fso_dir.cc", line=94) at coda_assert.c:46
#3  0x0808a3e1 in choke (file=0x80d73e9 "fso_dir.cc", line=94, 
    fmt=0x80d7480 "fsobj::dir_Create: (%s, %x.%x.%x) Create failed!")
    at venusutil.cc:209
#4  0x0806fbe6 in fsobj::dir_Create (this=0x26218108, 
    Name=0x8130bf0 "db_integration-de.dia", Fid=0x2554820c) at fso_dir.cc:94
#5  0x08063683 in fsobj::LocalCreate (this=0x26218108, Mtime=1070014155, 
    target_fso=0x25548208, name=0x8130bf0 "db_integration-de.dia", 
    Owner=10157, Mode=420) at fso_cfscalls0.cc:1648
#6  0x0806426f in fsobj::ConnectedCreate (this=0x26218108, Mtime=1070014155, 
    vuid=10157, t_fso_addr=0x151b1dac, name=0x8130bf0 "db_integration-de.dia", 
    Mode=420, target_pri=62500) at fso_cfscalls0.cc:1798
#7  0x08064e55 in fsobj::Create (this=0x26218108, 
    name=0x8130bf0 "db_integration-de.dia", target_fso_addr=0x151b1dac, 
    vuid=10157, Mode=420, target_pri=62500) at fso_cfscalls0.cc:1975
#8  0x080ab842 in vproc::create (this=0x812f6a0, dcp=0x151b3ed0, 
    name=0x8130bf0 "db_integration-de.dia", vap=0x8130b8c, excl=0, mode=33188, 
    cp=0x151b3e30) at vproc_vfscalls.cc:726
#9  0x080af092 in worker::main (this=0x812f6a0) at worker.cc:1155
#10 0x080a5cd2 in VprocPreamble (init_lock=0x812f6e0) at vproc.cc:146
#11 0x400922f0 in Create_Process_Part2 () at lwp.c:796
Received on 2003-11-28 05:26:27