__color__ ticket summary component version milestone type owner status created _changetime _description _reporter 1 1647 reintegration and shadow copies coda Coda-7.0.0 defect jaharkes assigned 2008-04-10T11:48:10Z-0400 2009-01-21T11:26:02Z-0500 "There are several problems when we create shadow copies for reintegration. A shadow copy for a container file is created so that a new writer doesn't clobber the data we want to reintegrate. We currently create these copies when reintegration starts, but there are several issues with this. a. If the file is not written to during reintegration, we wasted resources making a unnecessary copy. b. If the file was already reopened for writing, the container may already be clobbered. In this case the client will trigger an assertion at some point because the file size is not what we expected. c. If the file is opened for writing after making the shadow copy, but the client crashes we lose both the shadow copy (not persistently stored) as well as the rewritten version as we move owrite files out of the way on startup because we don't trust their contents. A long time ago shadow copies were made when we opened a file for writing that had a CML entry. This solves cases (a) and (b), but it doesn't solve (c). We moved away from that implementation because it performed an swap of the original and shadow container files in case the original container file was being backfetched which in turn made us lose the newly written contents when venus was restarted even if we had a clean shutdown. The current idea is to go back to the old scheme of only copying on the open for write, but this time create a full clone of the current fsobj (a shadow fsobj). The cml entry remains associated with the original, but it will for the rest be unlinked and dereferenced to the point that once the cml entry is reintegrated or optimized away the fso can be recycled. The cloned fso will take over for the old one and will be the one that is opened for writing." jaharkes 3 332 Local Global Inconsistencies coda defect Coda developers new 1997-06-20T13:19:10Z-0400 2007-04-02T06:16:14Z-0400 "From: Subject: Local Global Inconsistencies Date: Fri, 20 Jun 1997 09:19:10 -0400 (EDT) With local global inconsistencies ""ls -l"" leads to a hang from time to time. - Peter - " anonymous 3 602 crash of rossini coda defect Coda developers new 1997-06-24T15:20:43Z-0400 2007-04-02T06:16:27Z-0400 "From: Subject: crash of rossini Date: Tue, 24 Jun 1997 11:20:43 -0400 (EDT) Rossini crashed this morning with the following message: I believe this bug is fixed by now. 08:01:05 VInitVolPackage: HashInsert failed! Two d700050a volumes exist! Assertion failed: file ""/coda/project/coda/beta-clones/beta-11Jun1996_32041/src/ rvmres/resfile.c"", line 184 " anonymous 3 334 volutil salvage doesnt work coda defect Coda developers new 1997-06-27T15:00:20Z-0400 2007-04-02T06:16:39Z-0400 "From: Subject: volutil salvage doesn't work Date: Fri, 27 Jun 1997 11:00:20 -0400 (EDT) Josh says this routine doesn't work. Needs fixing. " anonymous 3 337 rvmlib_internal_malloc defect new 1997-07-03T12:21:10Z-0400 2004-05-21T17:08:39Z-0400 "From: Subject: rvmlib_internal_malloc Date: Thu, 3 Jul 1997 08:21:10 -0400 (EDT) This routine can assert when a server has no more rvm space available. It is very essential that it suggest this may be case in the SrvLog to assist beginning system admins. Gdb is not a user interface... " anonymous 3 339 volumes which are not attached defect new 1997-07-03T22:07:25Z-0400 2004-05-21T17:08:40Z-0400 "From: Subject: volumes which are not attached Date: Thu, 3 Jul 1997 18:07:25 -0400 (EDT) server write out volumelist when it starts and attaches volumes. a non replicated volume which has not been attached will not be in this list and we lose the ability to find out what the volume name is. maybe a reverse lookup for the in volutil info helps, maybe not. " anonymous 3 340 creation of backup doesnt update vldb defect new 1997-07-08T13:14:50Z-0400 2004-05-21T17:08:40Z-0400 "From: Subject: creation of backup doesn't update vldb Date: Tue, 8 Jul 1997 09:14:50 -0400 (EDT) Backup volumes are created at night by the backup program (this is only the first time a backup is run for the volume). The backup program does not rebuild the vldb, so the backup volume will only appear online after through some other mechanism (e.g. create a new volume) bldvldb is called. In relation with this it should also be noted that the directory OldFiles does not get created automatically. In short: 1) when the backup program finishes it should trigger a rebuild of the vldb. This is one of the many situations where a data base approach to volumes would _really_ help. 2) the creatvolrep script should trigger a coda client into creating the oldfiles and mount points. " anonymous 3 628 hoard vs symlinks & mount points defect new 1997-07-09T02:59:56Z-0400 2004-05-21T17:10:00Z-0400 "From: Subject: hoard vs symlinks & mount points Date: Tue, 08 Jul 1997 22:59:56 -0400 When you ask it to hoard a pathname, it turns the leading part of the pathname into a volume ID and stores that. Unfortunately, it never notices if that binding becomes invalid, and will continue to bang on a nonexistent volume until the HDB is manually cleared. It also does the wrong thing with respect to symlinks (if you hoard /a/b/c/d and ""c"" is a symlink, you need to hoard /a, /a/b, /a/b/c (the link), /xxx (whatever the link points to), and /xxx/d. Furthermore, if the link is changed to point to /yyy, you need to forget about /xxx and /xxx/d and switch over to /yyy and /yyy/d. >From my distant memory of the code, something like 80% of the code is there, but the remainder would require a week or so of hard thought. Dave " anonymous 3 659 hoard daemon is depth-first defect new 1997-07-09T03:00:50Z-0400 2004-05-21T17:10:11Z-0400 "From: Subject: hoard daemon is depth-first Date: Tue, 08 Jul 1997 23:00:50 -0400 The hoard daemon is depth-first rather than breadth-first. That is, it assumes it will have a long enough period of connectivity to stat everything (of all priorities) before beginning to fetch things of high priority. While this is true on an Ethernet, it's not true over a phone line (the stat phase could take an hour in a large cache). It needs to somehow interleave status and fetching. " anonymous 3 341 utility programs have wrong exit status codes defect new 1997-07-09T03:24:12Z-0400 2004-05-21T17:08:40Z-0400 "From: Subject: utility programs have wrong exit status codes Date: Tue, 08 Jul 1997 23:24:12 -0400 piper% /usr/coda/etc/cfs la /afs /afs: Invalid argument piper% echo $status 0 I believe there are other examples. " anonymous 3 634 Venus: cache scan not in directory order coda defect Coda developers new 1997-07-09T03:29:36Z-0400 2007-04-02T06:18:47Z-0400 "From: Subject: Venus: cache scan not in directory order Date: Tue, 08 Jul 1997 23:29:36 -0400 When Venus starts up, it scans the cache directory to make sure that the container files match the metadata in RVM. Unfortunately, this scan is done in some order convenient to Venus rather than in Unix directory order. On Unix, this takes O(n**2) time rather than O(n), and I believe this actually matters when there are thousands of files in the cache. " anonymous 3 658 spy should mention files that dont exist coda defect Coda developers new 1997-07-09T03:37:45Z-0400 2007-04-06T03:45:12Z-0400 "From: Subject: spy should mention files that don't exist Date: Tue, 08 Jul 1997 23:37:45 -0400 If, prior to disconnection, I run spy in the background and run my job, and hoard everything that spy reports, that's still not enough: spy hasn't said which files I *failed* to open, or which directories I traversed on my way to the failure. This is a problem because modern versions of make will look for a file in multiple locations; ENOENT is a fine answer, but ETIMEDOUT is not. " anonymous 3 626 """hoard abort"" needed" defect new 1997-07-09T04:05:19Z-0400 2004-05-21T17:09:59Z-0400 "From: Subject: ""hoard abort"" needed Date: Wed, 09 Jul 1997 00:05:19 -0400 A hoard walk can be deadly over a weak connection (in part because it has no concept of pacing itself to allow demand work to go on), but once one has started there is no way to stop it except to force a disconnection. A ""hoard abort"" command, which would set a flag checked by the hoard daemon before each RPC, would be a big win in these situations. Davd " anonymous 3 656 volutil clone doesnt create the right name defect new 1997-07-11T13:22:07Z-0400 2004-05-21T17:10:10Z-0400 "From: Subject: volutil clone doesn't create the right name Date: Fri, 11 Jul 1997 09:22:07 -0400 If you give it no name, it should create a clone of .readonly instead it creates a volume with no name. If you have .readonly, .restored, .backup as the last component, it silently truncates it. " anonymous 3 660 setting MLEs requires InitMetaData defect new 1997-07-31T18:32:06Z-0400 2002-05-15T21:47:43Z-0400 "From: Subject: setting MLEs requires InitMetaData Date: Thu, 31 Jul 1997 14:32:06 -0400 Doing a cvs checkout of the NetBSD kernel source when a server is unvailable requires quite a few Modify Log Entries (there are thousands of files and CVS takes about 3 MLEs to check out a single file--create, store, rename). I reinitialized my Venus with -mles 14000 and that seemed to help quite a bit. But when I stuck ""-mles 14000"" onto the command line in /etc/rc.local, so I wouldn't have to remember the magic incantation, Venus wouldn't start. It says ""setting MLEs requires InitMetaData"". Would it be possible to convert that to a warning or to even consider it not a problem if I'm asking for as many MLEs as were created during the last init? Dave " anonymous 3 613 local repair needs to clean up after itself defect new 1997-08-07T16:12:01Z-0400 2004-05-21T17:09:55Z-0400 "From: Subject: local repair needs to clean up after itself Date: Thu, 7 Aug 97 12:12:01 EDT Venus crashed during a local repair of my mail directory. The fatal error below appeared immediately after I committed the changes from a ""discardalllocal"" command. The assertion means that an object marked for discard (Dying state) was not placed on the delete list. The log is in /coda/project/coda/bugs/spartacus-local-death.log.Z 0x41a76ecc : fid = (ffffffff.ffffffff.8bb), comp = <99><97>A8<90>Aences, vol = 0 state = Dying, stat = { 10, 2, 865352472, 2208, 0644, 1, File }, rc rights = 0 VV = {[ 18 22 22 0 0 0 0 0 ] [ 0 865269024 ] [ 0 ]} voltype = [0 0 1 0], ucb = 1, fake = 0, fetching = 0 local = 1 rep = 0, data = 0, owrite = 0, era = 1, dirty = 0, shadow = 0 mvstat = Normal parent = (ffffffff.ffffffff.8ba, 0), children = 0 priority = 25 (63615), hoard = [0, -2, 0], lastref = 0 mle_bindings = (0, 0), cleanstat = [-1, -1] cachefile = [ V3507, 30399, 0 ] refs = [0 0 0], openers = [0 0 0] lastresolved = 0 discread = 0 [ W(35) : 0000 : 11:45:24 ] fatal error -- fsobj::Delete: state != link " anonymous 3 611 local repair bug: commit failure defect new 1997-08-10T15:35:17Z-0400 2004-05-21T17:09:54Z-0400 "From: Subject: local repair bug: commit failure Date: Sun, 10 Aug 97 11:35:17 EDT During a local repair, I preserved several local changes, each of which succeeded. The commit failed with an EACESS (even though I had tokens). I then tried to repair the object again.Repair said: * b .netscape object not in conflict the object was still in its exploded state: > ls -l .netscape total 8 drwxrwxr-x 4 lily 65534 2048 Aug 10 11:23 global drwxrwxr-x 4 lily 65534 2048 Aug 10 11:03 local evidently repair did not call ""endrepair"" upon commit failure. I did a cfs endrepair and tried again. This time, repair said: * b .netscape a local-global-conflict repair session already in progress and again left the object in its exploded state. No useful messages appeared in the venus log. Lily " anonymous 3 655 Poulenc failed in S_VolNewDump() defect new 1997-08-13T14:53:19Z-0400 2004-05-21T17:10:09Z-0400 "From: Subject: Poulenc failed in S_VolNewDump() Date: Wed, 13 Aug 1997 10:53:19 -0400 (EDT) Hi, Poulenc failed yesterday morning (Aug 12, 97, 00:54:53). It received signal 11 in S_VolNewDump() when trying to dump the volume u.lily.french (group vol num is 0x7f000360, vol id is 0xe100000b, backup volume is 0xe1000029). The offending instruction is in S_VolNewDump() (vol-dump.cc:270) within the following context: /* Overload the fd parameter if using newstyle dump -- this will go away. */ dbuf = InitDumpBuf((byte *)DumpBuf, (long)DUMPBUFSIZE, V_id(vp), cid); DumpListVVHeader(VVListFd, vp, (int)*Incremental, (int)unique);/* Dump the volume.*/ if ((DumpDumpHeader(dbuf, vp, *Incremental, unique) == -1) || (DumpVolumeDiskData(dbuf, &V_disk(vp)) == -1) || (DumpVnodeIndex(dbuf, vp, vLarge, *Incremental) == -1) || (DumpVnodeIndex(dbuf, vp, vSmall, *Incremental) == -1) || => (DumpEnd(dbuf) == -1)) { LogMsg(0, VolDebugLevel, stdout, ""Dump failed due to FlushBuf failure.""); retcode = VFAIL; } SrvLog and SrvErr are kept in /coda/usr/clement/russian/bugs/poulenc-Aug12-97 -- Clement more info attached ------------------------------------------------------------------ (gdb) bt #0 0x101b25e9 in sigsuspend () #1 0x101afe48 in sleep () #2 0x2868a in zombie (sig=11, code=6, scp=0x56899c) at /afs/cs/user/clement/secsrc5/coda-src/vice/srv.cc:340 #3 #4 0x101b8a5c in bzero () #5 0x64fbf in DumpVnodeIndex (dbuf=0xfc68c0, vp=0x468080, vclass=1, Incremental=16) at /afs/cs/project/coda-src/alpha/coda-src/volutil/vol-dump.cc:446 #6 0x63e18 in S_VolNewDump (rpcid=65658, formal_volumeNumber=3774873641, Incremental=0x568f38) at /afs/cs/project/coda-src/alpha/coda-src/volutil/vol-dump.cc:270 #7 0x4d48c in _S_VolNewDump (_cid=65658, _reqbuffer=0x57d800, _bd=0x0) at volutil.server.cc:414 #8 0x4e745 in volUtil_ExecuteRequest (_cid=65658, _reqbuffer=0x57d800, _bd=0x0) at volutil.server.cc:1094 #9 0x2e39c in VolUtilLWP (myindex=0xf7bfd834) at /afs/cs/project/coda-src/alpha/coda-src/volutil/volutil.cc:163 #10 0x13f557 in Create_Process_Part2 () at /afs/cs/project/coda-src/alpha/lib-src/mlwp/lwp.c:1091 #11 0x141986 in savecontext () #12 (gdb) info frame Stack level 6, frame at 0x568f20: eip = 0x63e18 in S_VolNewDump(long, unsigned long, unsigned long *) (/afs/cs/project/coda-src/alpha/coda-src/volutil/vol-dump.cc:270); saved eip 0x4d48c called by frame at 0x568f50, caller of frame at 0x568d50 source language c++. Arglist at 0x568f20, args: rpcid=65658, formal_volumeNumber=3774873641, Incremental=0x568f38 Locals at 0x568f20, Previous frame's sp is 0x0 Saved registers: ebx at 0x568d68, ebp at 0x568f20, esi at 0x568d6c, edi at 0x568d70, eip at 0x568f24 (gdb) /*typedef enum {vLarge=0,vSmall=1} VnodeClass;*/ #define vLarge 0 #define vSmall 1 #define V_disk(vp) ((vp)->header->diskstuff) (gdb) p dbuf $7 = (DumpBuffer_t *) 0xfc68c0 (gdb) p vp $8 = (Volume *) 0x468080 (gdb) p Incremental $9 = (long unsigned int *) 0x568f38 (gdb) p unique $10 = 68020 (gdb) p &(vp->header->diskstuff) $11 = (VolumeDiskData *) 0x2777d0 ------------------------------------------------------------------ " anonymous 3 607 Repair doesnt notice problem defect new 1997-08-26T01:10:28Z-0400 2002-05-15T21:44:17Z-0400 "From: Subject: Repair doesn't notice problem Date: Mon, 25 Aug 1997 21:10:28 -0400 I have an inconsistent directory: /coda/usr/mre/testing. One version of /coda/usr/mre/testing/foo was created on scarlatti; a different one on puccini and rossini. The repair-in-progress view of /coda/usr/mre/testing is: mre% ls -l * puccini.coda.cs.cmu.edu: total 4 -rw-r--r-- 1 mre 65534 0 Aug 25 20:51 foo drwxr-xr-x 2 mre 65534 2048 Aug 8 17:33 testing2 rossini.coda.cs.cmu.edu: total 4 -rw-r--r-- 1 mre 65534 0 Aug 25 20:51 foo drwxr-xr-x 2 mre 65534 2048 Aug 4 16:57 testing2 scarlatti.coda.cs.cmu.edu: total 4 -rw-r--r-- 1 mre 65534 21 Aug 25 20:46 foo drwxr-xr-x 2 mre 65534 2048 Aug 4 16:57 testing2 ---------------------------------------------------------------- When I try to repair this object, repair doesn't notice that foo is different: mre% repair This repair tool can be used to manually repair server/server or local/global conflicts on files and directories. You will first need to do a ""beginrepair"" to start a repair session where messages about the nature of the conflict and the commands that should be used to repair the conflict will be displayed. Help message on individual commands can also be obtained by using the ""help"" facility. Finally, you can use the ""endrepair"" or ""quit"" to terminate the current repair session. * b Pathname of object in conflict? [] testing a server-server-conflict repair session started use the following commands to repair the conflict: comparedirs removeinc dorepair * com Pathname of Object in conflict? [testing] Pathname of repair file produced? [] /tmp/t.r The fix file may be empty but .... You still need a dorepair because the Version state is different Operations to resolve conflicts are in /tmp/t.r ---------------------------------------------------------------- The contents of /tmp/t.r include: mre% cat /tmp/t.r replica PUCCINI.CODA.CS.CMU.EDU d8000380 replica ROSSINI.CODA.CS.CMU.EDU d7000380 replica SCARLATTI.CODA.CS.CMU.EDU d6000380 ---------------------------------------------------------------- I've been creating inconsistencies all day in roughly the same way. (I don't suppose any of yunz remember Puneet's cute little trick to mark an object inconsistent without it really being inconsistent, do you?) Everything has been working fine up until now so I suspect this is a relatively rare problem. Since this is a throw-away directory, I'll leave it around for whenever we find time to look at it. I can't remember, but I believe that I had already done a run of repair and that it didn't completely solve the problem. This is confirmed by the fact that one version of foo is of zero length. The version I originally created was not. The first run of foo would have requested that all three version of the file be removed. Scarlatti's /vicepb is at 96% full so I suppose it is possible that my first repair failed to remove the file and I didn't notice. However, if that's the case, I should be able to rerun repair and have it go through correctly. Maria " anonymous 3 622 fsobj::UnmountRoot: no u.mtpoint! defect new 1997-08-28T13:41:50Z-0400 2004-05-21T17:09:58Z-0400 "From: Subject: fsobj::UnmountRoot: no u.mtpoint! Date: Thu, 28 Aug 97 9:41:50 EDT Venus died with this fatal error while attempting to localize a subtree after a reintegration failure. The fso in question was the root of a volume. Log is in /coda/project/coda/bugs/nomtpt.log.Z " anonymous 3 620 cmlent::QueryReintegrationHandle: offset > length! defect new 1997-08-29T18:21:46Z-0400 2004-05-21T17:09:57Z-0400 "From: Subject: cmlent::QueryReintegrationHandle: offset > length! Date: Fri, 29 Aug 97 14:21:46 EDT venus died with this error shortly after startup, after attempting to continue a partial reintegration. log and console are in /coda/project/coda/bugs/offset.log.Z and offset.console. " anonymous 3 619 "venus crashed with ""fsobj::Delete: state != link""" defect new 1997-10-14T01:52:56Z-0400 2004-05-21T17:09:57Z-0400 "From: Subject: venus crashed with ""fsobj::Delete: state != link"" Date: Mon, 13 Oct 1997 21:52:56 -0400 (EDT) Hi, Venus crashed when I did a ""cfs flushvolume"". I have had attemped a local repair, but it failed to do a ""preservelocal"". The repair process seemed to be just sitting there and doing nothing, so I killed the repair process. But then the exposed local and global subtree appeared under the inconsistent object. This force me to do a ""cfs flushvolume"" and venus crashed... The crashing message of venus is ""fsobj::Delete: state != link"". The object was marked ""Dying"", but it's not put into the delete queue. -- Clement Venus.log is kept in /coda/usr/clement/russian/crashdump/venus.log.Oct13_97.Z void fsobj::Kill(int TellServers) { #ifdef VENUSDEBUG /* Sanity check. */ => if ((DYING(this) && *((dlink **)&del_handle) == 0) || (!DYING(this) && *((dlink **)&del_handle) != 0)) { print(logFile); Choke(""fsobj::Delete: state != link""); } #endif VENUSDEBUG 0x2185bfcc : fid = (7f00032b.7.2), comp = , vol = 0 state = Dying, stat = { 2048, 61, 858056824, 6822, 0755, 7, Directory }, rc rights = 0 VV = {[ 61 61 61 0 0 0 0 0 ] [ 0x8002de30 857758136 ] [ 0 ]} ac rights = { [7f 10] [-1 0 00] [-1 0 00] [-1 0 00] [-1 0 00] [-1 0 00] [-1 0 00] [-1 0 00] [6822 7f 10] } voltype = [0 0 1 0], ucb = 1, fake = 0, fetching = 0 local = 0 rep = 0, data = 0, owrite = 0, era = 1, dirty = 0, shadow = 0 mvstat = Normal parent = (7f00032b.1.1, 0), children = 0 priority = 20200 (46996), hoard = [0, -2, 0], lastref = 0 mle_bindings = (0, 0), cleanstat = [-1, -1] cachefile = [ V2773, 173861, 0 ] directory = 0 refs = [0 0 0], openers = [0 0 0] lastresolved = 0 discread = 0 [ W(669) : 0000 : 20:42:17 ] fatal error -- fsobj::Delete: state != link (gdb) bt #0 0x400ea854 in sigsuspend (__sigmask=0x4025f840) #1 0x401094e8 in __DTOR_END__ () #2 0x80e1de0 in SEGV (sig=11, code=43, contextPtr=0x2b) at /afs/cs/user/clement/ss/coda-src/venus/sighand.cc:189 #3 0x4025f6a8 in ?? () #4 0x8068a45 in fsobj::Kill (this=0x2185bfcc, TellServers=1) at /home/clement/ah/ma/coda-src/venus/fso1.cc:656 #5 0x8068f5d in fsobj::Flush (this=0x2185bfcc) at /home/clement/ah/ma/coda-src/venus/fso1.cc:730 #6 0x80615ad in fsdb::Flush (this=0x2199584c, vid=2130707243) at /home/clement/ah/ma/coda-src/venus/fso0.cc:1470 #7 0x813875b in vproc::do_ioctl (this=0x8310f28, fid=0x82c6040, com=1074550309, data=0x4025ff98) at /home/clement/ah/ma/coda-src/venus/vproc_pioctl.cc:620 #8 0x813bf12 in vproc::ioctl (this=0x8310f28, vp=0x82d0bc8, com=1074550309, data=0x4025ff98, flags=0) at /home/clement/ah/ma/coda-src/venus/vproc_vfscalls.cc:424 #9 0x8141241 in worker::main (this=0x8310f28, parm=0x8133394) at /home/clement/ah/ma/coda-src/venus/worker.cc:983 #10 0x81334b1 in VprocPreamble (init_lock=0x8310f6c) at /home/clement/ah/ma/coda-src/venus/vproc.cc:173 #11 0x816b87a in Create_Process_Part2 () at /home/clement/ah/ma/lib-src/mlwp/lwp.c:1091 #12 0x816d7ab in L1 () #13 0x805304ec in ?? () (gdb) up #5 0x8068f5d in fsobj::Flush (this=0x2185bfcc) at /home/clement/ah/ma/coda-src/venus/fso1.cc:730 (gdb) p this $2 = (fsobj *) 0x2185bfcc (gdb) p *this $3 = {MagicNumber = 2687694, fid = {Volume = 2130707243, Vnode = 7, Unique = 2}, comp = 0x2169088c """", vol = 0x0, primary_handle = { next = 0x217017e4}, vol_handle = {next = 0x0, _vptr. = 0x81d6774 }, prio_handle = {mytree = 0x0, parent = 0x0, leftchild = 0x0, rightchild = 0x0, _vptr. = 0x81d69b0 }, del_handle = {next = 0x0, prev = 0x0, _vptr. = 0x81d687c }, owrite_handle = { next = 0x0, _vptr. = 0x81d6774 }, state = FsoDying, stat = {VnodeType = Directory, LinkCount = 7 '\a', Length = 2048, DataVersion = 61, VV = {Versions = {Site0 = 61, Site1 = 61, Site2 = 61, Site3 = 0, Site4 = 0, Site5 = 0, Site6 = 0, Site7 = 0}, StoreId = { Host = 2147671600, Uniquifier = 857758136}, Flags = 0}, Date = 858056824, Author = 4294967295, Owner = 6822, Mode = 493}, RcRights = 0, AnyUser = {uid = 4294967295, rights = 127 '\177', inuse = 1, valid = 0} Debugger segmentation fault (core dumped) " anonymous 3 618 Hoard doesnt defect new 1997-10-15T22:13:37Z-0400 2002-05-15T21:45:13Z-0400 "From: Subject: Hoard doesn't Date: Wed, 15 Oct 1997 18:13:37 -0400 I had a directory tree hoarded with d+:1000 (my thesis, as it happens), and had been working on it from home over a phone line. This is from my home desktop, which is never connected at better than phone line speeds. After a weakly connected reintegration of the tree, (backfetch to one server, force a resolve, and refetch on next hoard walk), a moderately large (200KB) postscript file wasn't refetched. I think that Venus thought the file was too big for my patience, since running `file` on the postscript forced my Venus to fetch the file. If I have something hoarded at 1000, that should mean that I'm ""infinitely patient"" and want it no matter the cost. Aside #1: I've changed all my hoard priorities on my home machine to 1000, because I've been burned by patience in the past, and was hoping that I could avoid the patience model entirely with 1000. It seems that Coda's philosophy of ""thou shalt not tie up the network for more than K seconds"" is a good one. But, why don't we treat Fetch as we treat Reintegrate? Right now, reintegrate if faced with a big file does it in chunks. However, if fetch is faced with a big file, it gives up. Why not fetch in chunks as well? I think this would be far superior. Aside #2: I'm not convinced that the fetch-after-resolve step in weak-reintegration is necessary. Just as the servers have a notion of weakly-equal replicas, would it also not be possible to allow clients to determine that their version is weakly-equal to the newly-resolved copy on the servers? This is probably not easy to implement, but it would be a Big Win (tm) for our eternally-weakly-connected users. -brian " anonymous 3 650 Volume Database Bug defect new 1997-10-22T15:22:13Z-0400 2002-05-15T21:47:12Z-0400 "From: Subject: Volume Database Bug Date: Wed, 22 Oct 1997 11:22:13 -0400 (EDT) Henry, Here is a bug for you to fix. During the night the backup program will run. It will create new volumes on servers which are read only clones of existing volumes at the time of the dump. The problem is that these are not propagated to the VLDB which is done with the somewhat involved process of calling the bldvldb.sh script. So on scarlatti bldvldb.sh will have to run with cron probably early in the morning (5am). I think that these are not replicated volumes, so perhaps the VRDB doesn't matter, but I want you to inspect that, and rebuild that too. It would in fact be very useful to have a script that rebuilds the VRDB (if this is possible). Peter " anonymous 3 648 rossini crashed in resolution (ObtainDirOps()) defect new 1997-11-05T03:28:45Z-0500 2002-05-15T21:47:06Z-0400 "From: Subject: rossini crashed in resolution (ObtainDirOps()) Date: Tue, 4 Nov 1997 22:28:45 -0500 (EST) Hi, When I was trying to do a ""ls"" on a volume hosted on italian servers, rossini crashed. I leave the server as is, just in case Peter want to debug it. SrvLog 22:17:20 FileResolve: 2 dominant copies 22:17:20 Entering RecovDirResolve (0x7f000308.6df.2b05) 22:17:20 ****** FILE SERVER INTERRUPTED BY SIGNAL 11 CODE 0 ****** 22:17:20 ****** Aborting outstanding transactions, stand by... 22:17:20 Uncommitted transactions: 0 22:17:20 Uncommitted transactions: 0 22:17:20 To debug via gdb: attach 1420, setcontext OldContext 22:17:20 Becoming a zombie now ........ SrvErr Assertion failed: file ""/usr1/braam/cs/coda-src/res/resforce.cc"", line 506 The line seems to be in ObtainDirOps() int error = 0; VPutVnode((Error *)&error, vptr); assert(error == 0); => assert(strlen(name) < (DIROPNAMESIZE)); diroplink *direntry = new diroplink(op, vnode, unique, name); /* now insert the entry into the list */ gdop->oplist->append(direntry); The volume is u.clement. I forgot what the directory is for, but it is very probable that it is one of those directories where I tested very nasty things (long time ago) such as very long file name. -- Clement " anonymous 3 644 bad message when resolution log is full defect new 1998-01-20T21:38:27Z-0500 2002-05-15T21:46:51Z-0400 "From: Subject: bad message when resolution log is full Date: Tue, 20 Jan 1998 16:38:27 -0500 (EST) The message is: 5 16:34:36 AllocRecord: No space left in volume log. It should mention the volume. Peter " anonymous 3 643 adding a server defect new 1998-01-30T16:43:44Z-0500 2004-05-21T17:10:04Z-0400 "From: Subject: adding a server Date: Fri, 30 Jan 1998 11:43:44 -0500 (EST) When a server is added likely a new entry is made in /vice/db/servers. Sadly this file is not reloaded when the server prints ""New databases arrived!"". As a result currently _all_ servers must be restarted when this file changes. It should be pretty straightforward to fix this. Peter " anonymous 3 642 Salvage bug coda defect Coda developers new 1998-03-30T16:04:28Z-0500 2007-04-02T06:18:34Z-0400 "From: Subject: Salvage bug Date: Mon, 30 Mar 1998 11:04:28 -0500 (EST) I have been worried for a while about the fact that many inconsistencies can arise between vnodes and server inodes (real ""files""). The vnode creations and deletions are done in transactions and _afterwards_ the file system routines are invoked to create/remove the files using ""icreate"", ""idec"" etc. It appears that a volume on massenet got into a state where the salvager was not able to fix things -- resulting a in a volume which we lost (we could resolve it from other replicas). The problem happens in #0 0x80add6c in VnodeInodeCheck (RW=1, ip=0x40261788, nInodes=14, vsp=0x81a39fc) at ../../../coda-4.3.13/coda-src/volutil/vol-salvage.cc:735 #1 0x80acfa3 in SalvageVolumeGroup (vsp=0x81a39fc, nVols=2) at ../../../coda-4.3.13/coda-src/volutil/vol-salvage.cc:486 Something in the routine goes badly wrong and the salvager finds a lot of bad vnodes -- which it can correct if -debarrenize is given as a server startup option. However, things get confused and at the end of the day, the list of vnodes does not seem to have been correctly iterated over -- an assertion on the line assert(nVnodes == 0); stops the server. We'll have to investigate this systematically one day. - Peter - " anonymous 3 637 Re: Small coda installation buglet defect new 1998-05-26T14:49:29Z-0400 2004-05-21T17:10:02Z-0400 "From: Subject: Re: Small coda installation buglet Date: Tue, 26 May 1998 10:49:29 -0400 (EDT) Thanks! We'll fix it. Peter On 26 May 1998, Alexey Goldin wrote: > ""Peter J. Braam"" writes: > > > > > > > > > Turns up vicetab is : > > > > > > spot /vicepa ftree width=64,depth=3 > > > ^^^^^^ > > > > That's your hostname. > > > > > > > > > > > while the short session on makeftree with gdb demontrated that > > > makeftree expects to find spot.uchicago.edu (full name) there. > > > > I don't think so; I think that it can't find /vicepa, that is what is > > printed out above you see. > > > /vicepa did exist, this is why it was so difficult to find out what > happened. After I manually replaced spot to spot.uchicago.edu, I could > get further. > > " anonymous 3 616 Bug in klog (Was: Re[2]: Many Questions :-)) defect new 1998-09-08T08:40:08Z-0400 2004-05-21T17:09:55Z-0400 "From: Subject: Bug in klog (Was: Re[2]: Many Questions :-)) Date: Tue, 8 Sep 1998 08:40:08 +0000 ( ) I have found a bug in kclog: When you forget -host (i.e running ""kclog -kerberos5 manuel"" for exemple), It crach in krbsupport.c line 304 when calling gethostbyname in krb5GetSecret because hostname is null. The problem is that there is no test to verify that the host option was set in clog.c Do I send bug reports to the list or... ? Thank you very much for your time. Manuel -- ____________________________________________________________________ Manuel GUESDON - SOFTWARE BUILDERS http://www.sbuilders.com PGP Key Id: 12C3E391 PGP Signed/Encrypted mails prefered " anonymous 3 273 more BSD bugs defect new 1998-09-12T19:12:58Z-0400 2003-06-11T14:04:27Z-0400 "From: Subject: more BSD bugs Date: Sat, 12 Sep 1998 15:12:58 -0400 (EDT) 1. mount on FreeBSD does not show a correct mount entry 2. cfs sa under FreeBSD seems to not use the euid, but the uid; this is not correct. " anonymous 3 283 Volume oddity defect new 1998-10-05T00:14:13Z-0400 2002-05-15T21:28:02Z-0400 "From: Subject: Volume oddity Date: Sun, 4 Oct 1998 20:14:13 -0400 (EDT) We noticed that the current blocks used seems a little odd : cfs lv robert Status of volume 0x7f000002 (2130706434) named ""robert.l"" Volume type is ReadWrite Minimum quota is 0, maximum quota is unlimited Current blocks used are 4294890575 The partition has 1001163 blocks available out of 3960448 We're not sure how it got this way, but prior to noticing this, we were untarring a Coda build into that volume, while write-disconnected for a brief period, followed by reconnection while the tar was still going on. We unfortunately lost the venus messages, but the untar stalled and venus reponded to a kill by starting to shutdown, but didn't finish for several minutes and then did not respond to a kill -9 These are the messages from the server around that time : 19:13:30 VAllocFid: volume disk uniquifier being extended 19:13:52 ViceValidateAttrs: (2a00000b.2f.ea) failed! 19:14:07 VAllocFid: volume disk uniquifier being extended 19:14:18 VAllocFid: volume disk uniquifier being extended 19:14:18 GrowVnodes: growing Small list from 256 to 512 for volume 0x2a000012 19:14:18 CheckSymlinkSemantics: rights violation (8 : 8) (2a000012.1.1) 19:14:18 Entering VFlushVnode for vnode 1 19:14:18 Entering VFlushVnode for vnode 496 19:14:19 GrowVnodes: growing Large list from 384 to 512 for volume 0x2a00000b 19:14:19 GrowVnodes: growing Small list from 2560 to 2816 for volume 0x2a00000b 19:14:21 PutReintegrateObjects: stale directory fid 0x7f000002.2eb.b88, num 0, max 50 19:14:40 VAllocFid: volume disk uniquifier being extended 19:14:47 PutReintegrateObjects: stale directory fid 0x7f000002.357.c1e, num 0, max 50 19:15:14 VAllocFid: volume disk uniquifier being extended 19:15:40 ViceValidateAttrs: (2a00000b.2f.ea) failed! 19:15:40 ViceValidateAttrs: (2a00000b.2f.ea) failed! 19:16:00 FetchBulkTransfer: CheckSE failed (-2014), (2a00000b.768.45c) 19:16:11 ViceValidateAttrs: (2a00000a.43.1f2) failed! 19:16:12 ViceValidateAttrs: (2a00000a.43.1f2) failed! 19:17:17 Worker4: Unbinding RPC connection 131178 19:17:19 ViceValidateAttrs: (2a00000b.2f.ea) failed! 2a00000b is this (robert's) volume, and 2a00000a is the root volume. We're going to try a similar set of events on another volume & see what happens. Meanwhile is there some way to fix the volume info ? Shafeeq " anonymous 3 292 Permission Denied on mv under FreeBSD 3.0-CURRENT coda defect Coda developers new 1998-10-13T04:15:13Z-0400 2007-04-06T03:44:42Z-0400 "From: Subject: Permission Denied on mv under FreeBSD 3.0-CURRENT Date: Tue, 13 Oct 1998 00:15:13 -0400 (EDT) I have tokens, and am attempting to move a file into Coda: % pwd /coda/robert/private/nes/NES % id uid=1000(robert) gid=1000(robert) groups=1000(robert), 0(wheel), 5(operator), 68(dialer), 500(mud), 501(mods), 502(shop), 801(cddata), 802(unixdev), 900(admin), 1004(www), 1060(mccann) % ls -l /tmp/xses-robert -rw------- 1 robert bin 947 Aug 8 20:10 /tmp/xses-robert % mv /tmp/xses-robert . mv: ./xses-robert: Permission denied % head -1 /tmp/xses-robert # the output for this command is correct,btw QDir::readDirEntries: Cannot read the directory:/homea/robert/Desktop/Template % ls -l xses-robert ---------- 1 robert nobody 0 Oct 13 00:10 xses-robert % rm xses-robert override --------- robert/nobody for xses-robert? y % cat /tmp/xses-robert > xses-robert % head -1 xses-robert QDir::readDirEntries: Cannot read the directory:/homea/robert/Desktop/Templates Here is a ktrace for the failed mv: 4557 ktrace RET ktrace 0 4557 ktrace CALL readlink(0x200742a2,0xefbfcf28,0x3f) 4557 ktrace NAMI ""/etc/malloc.conf"" 4557 ktrace RET readlink -1 errno 2 No such file or directory 4557 ktrace CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) 4557 ktrace RET mmap 536965120/0x20017000 4557 ktrace CALL break(0x8000) 4557 ktrace RET break 0 4557 ktrace CALL break(0x9000) 4557 ktrace RET break 0 4557 ktrace CALL execve(0xefbfd030,0xefbfd4f8,0xefbfd508) 4557 ktrace NAMI ""/homea/robert/bin/mv"" 4557 ktrace RET execve -1 errno 2 No such file or directory 4557 ktrace CALL execve(0xefbfd030,0xefbfd4f8,0xefbfd508) 4557 ktrace NAMI ""/bin/mv"" 4557 mv RET execve 0 4557 mv CALL stat(0xefbfd5c0,0xefbfd48c) 4557 mv NAMI ""."" 4557 mv RET stat 0 4557 mv CALL access(0xefbfd08c,0) 4557 mv NAMI ""./xses-robert"" 4557 mv RET access -1 errno 2 No such file or directory 4557 mv CALL rename(0xefbfd5af,0xefbfd08c) 4557 mv NAMI ""/tmp/xses-robert"" 4557 mv NAMI ""./xses-robert"" 4557 mv RET rename -1 errno 18 Cross-device link 4557 mv CALL open(0x1e10,0,0xefbfcae8) 4557 mv NAMI ""."" 4557 mv RET open 3 4557 mv CALL chdir(0xefbfcae8) 4557 mv NAMI ""/tmp"" 4557 mv RET chdir 0 4557 mv CALL lstat(0xefbfcaed,0xefbfca6c) 4557 mv NAMI ""xses-robert"" 4557 mv RET lstat 0 4557 mv CALL sigaction(0xc,0xefbfc5d8,0xefbfc5cc) 4557 mv RET sigaction 0 4557 mv CALL __getcwd(0xefbfcae8,0x400) 4557 mv RET __getcwd 0 4557 mv CALL sigaction(0xc,0xefbfc5cc,0) 4557 mv RET sigaction 0 4557 mv CALL fchdir(0x3) 4557 mv RET fchdir 0 4557 mv CALL close(0x3) 4557 mv RET close 0 4557 mv CALL statfs(0xefbfcae8,0xefbfcee8) 4557 mv NAMI ""/tmp/xses-robert"" 4557 mv RET statfs 0 4557 mv CALL stat(0xefbfd5af,0xefbfcff8) 4557 mv NAMI ""/tmp/xses-robert"" 4557 mv RET stat 0 4557 mv CALL open(0xefbfd5af,0,0) 4557 mv NAMI ""/tmp/xses-robert"" 4557 mv RET open 3 4557 mv CALL readlink(0x1efae,0xefbfca44,0x3f) 4557 mv NAMI ""/etc/malloc.conf"" 4557 mv RET readlink -1 errno 2 No such file or directory 4557 mv CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) 4557 mv RET mmap 537022464/0x20025000 4557 mv CALL break(0x30000) 4557 mv RET break 0 4557 mv CALL break(0x32000) 4557 mv RET break 0 4557 mv CALL open(0xefbfd08c,0xe01,0) 4557 mv NAMI ""./xses-robert"" 4557 mv RET open -1 errno 13 Permission denied 4557 mv CALL write(0x2,0xefbfc3ac,0x4) 4557 mv GIO fd 2 wrote 4 bytes ""mv: "" 4557 mv RET write 4 4557 mv CALL write(0x2,0xefbfc3c0,0xd) 4557 mv GIO fd 2 wrote 13 bytes ""./xses-robert"" 4557 mv RET write 13/0xd 4557 mv CALL write(0x2,0xefbfc3a4,0x2) 4557 mv GIO fd 2 wrote 2 bytes "": "" 4557 mv RET write 2 4557 mv CALL write(0x2,0xefbfc3a8,0x12) 4557 mv GIO fd 2 wrote 18 bytes ""Permission denied "" 4557 mv RET write 18/0x12 4557 mv CALL close(0x3) 4557 mv RET close 0 4557 mv CALL exit(0x1) Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ " anonymous 3 617 Coda w/ Kerberos5 coda defect reopened 1998-10-13T19:53:58Z-0400 2009-09-20T19:54:04Z-0400 "From: Subject: Coda w/ Kerberos5 Date: Tue, 13 Oct 1998 15:53:58 -0400 Full_Name: Mark Ferrell Version: 4.6.5 OS: Linux Submission from: morbeck.kdi.com (208.24.207.28) in coda-src/auth2/clog.c line 129, there is a test for -host in the code. This test only happens if -host is specified and is not enforced to used. If you leave out -host then later in clog.c linx 163, hostname is used when it can likley be null. I.E. -host was not specified on the command line. This causes the following fun. Date: Tue 10/13/98 09:53:24 In Krb5GetKeys() Segmentation fault " anonymous 3 294 delays in disconnected operation defect new 1998-10-13T23:30:45Z-0400 2002-05-15T21:28:38Z-0400 "From: Subject: delays in disconnected operation Date: Tue, 13 Oct 1998 19:30:45 -0400 (EDT) While operating disconnected, I experience a fairly long delay when performing simple file operations. This has only happened once, but sure is annoying. % time ls nes trace-modulation wl 0.000u 0.005s 0:03.14 0.0% 0+0k 0+0io 0pf+0w (three seconds to ls seems a bit high). All of the information should be in the venus cache, and hoarded. This is under coda-head on 3.0-CURRENT of FreeBSD. " anonymous 3 615 kau fails to validate defect new 1998-10-15T08:54:48Z-0400 2004-05-21T17:09:55Z-0400 "From: Subject: kau fails to validate Date: Thu, 15 Oct 1998 04:54:48 -0400 Full_Name: Mark Ferrell Version: coda-4.6.6 OS: Linux-2.1.125 Submission from: morbeck.kdi.com (208.24.207.28) It might be just me but the kau fails misserably for me when trying to add a new user. For some reason or another it rejects my attempts to validate myself via the kerberos passwords or the coda passwords I created for the admin accound. [root@satan /root]# kau -h satan nu Your Vice name: admin Your password: RPC2_Bind() --> RPC2_NOTAUTHENTICATED (F) Curious if this is a known problem I just didn't see anything about or if there is some special proceedure I am missing. --Mark " anonymous 3 300 12:39:35 cant checkpoint (./private/coda/3.0/bd/config.log), no data defect new 1998-10-25T18:39:31Z-0500 2004-05-21T17:08:30Z-0400 "From: Subject: 12:39:35 can't checkpoint (./private/coda/3.0/bd/config.log), no data Date: Sun, 25 Oct 1998 13:39:31 -0500 (EST) While operating remotely, poorly (although probably not weakly?) connected, I was performing a cvs checkout into coda. For some reason, Venus decided to start logging changes (I guess it decided trickle-back was the way to go). After a while, a conflict developed: (/usr/coda/etc/console: 23:01:06 worker::Return: message write error 3 (op = 10, seq = 285084), wrote -1 of 28 bytes 12:20:52 Checkpointing robert.l 12:20:52 to /usr/coda/spool/1000/robert.l@|coda|robert.tar 12:20:52 and /usr/coda/spool/1000/robert.l@|coda|robert.cml 12:29:25 Reintegrate: robert.l, 20/335 records, result = SUCCESS 12:29:36 Reintegrate: robert.l, 25/315 records, result = SUCCESS 12:29:46 Reintegrate: robert.l, 15/290 records, result = SUCCESS 12:29:57 Reintegrate: robert.l, 25/275 records, result = SUCCESS 12:30:04 Reintegrate: robert.l, 15/250 records, result = SUCCESS 12:30:25 Reintegrate: robert.l, 20/235 records, result = SUCCESS 12:30:38 Reintegrate: robert.l, 15/215 records, result = SUCCESS 12:30:46 Reintegrate: robert.l, 5/200 records, result = SUCCESS 12:30:54 Checkpointing robert.l 12:30:54 to /usr/coda/spool/1000/robert.l@|coda|robert.tar 12:30:54 and /usr/coda/spool/1000/robert.l@|coda|robert.cml 12:31:04 Reintegrate: robert.l, 5/195 records, result = SUCCESS 12:31:16 Reintegrate: robert.l, 10/190 records, result = SUCCESS 12:31:26 Reintegrate: robert.l, 10/180 records, result = SUCCESS 12:31:35 Reintegrate: robert.l, 10/170 records, result = SUCCESS 12:31:47 Reintegrate: robert.l, 15/160 records, result = SUCCESS 12:31:58 Reintegrate: robert.l, 20/145 records, result = SUCCESS 12:32:06 Reintegrate: robert.l, 5/125 records, result = SUCCESS 12:32:17 Reintegrate: robert.l, 20/120 records, result = SUCCESS 12:32:29 Reintegrate: robert.l, 25/100 records, result = SUCCESS 12:32:36 Reintegrate: robert.l, 10/75 records, result = SUCCESS 12:32:40 DispatchWorker: signal received (seq = 315673) 12:32:40 worker::Return: message write error 3 (op = 10, seq = 315673), wrote -1 of 28 bytes 12:32:46 Reintegrate: robert.l, 10/65 records, result = SUCCESS 12:32:58 Reintegrate: robert.l, 5/55 records, result = SUCCESS 12:33:08 Reintegrate: robert.l, 20/50 records, result = SUCCESS 12:33:21 Reintegrate: robert.l, 10/30 records, result = SUCCESS 12:33:31 Reintegrate: robert.l, 10/20 records, result = SUCCESS 12:33:41 Reintegrate: robert.l, 5/10 records, result = SUCCESS 12:34:01 Reintegrate: robert.l, 5/5 records, result = SUCCESS 12:38:47 DispatchWorker: signal received (seq = 316516) 12:38:47 worker::Return: message write error 3 (op = 10, seq = 316516), wrote -1 of 28 bytes 12:39:35 Checkpointing robert.l 12:39:35 to /usr/coda/spool/1000/robert.l@|coda|robert.tar 12:39:35 and /usr/coda/spool/1000/robert.l@|coda|robert.cml 12:39:35 can't checkpoint (./private/coda/3.0/bd/config.log), no data 12:39:36 Local inconsistent object at /coda/robert/private/coda/3.0/bd/config.log, please check! 12:39:36 Reintegrate: robert.l, 1/1 records, result = Invalid argument 12:40:57 volume robert.l has unrepaired local subtree(s), skip checkpointing CML! 12:41:12 Local inconsistent object at /coda/robert/private/coda/3.0/bd/config.log, please check! Interestingly, there should have been no other activities going on against the volume in question, as it is my home directory volume, and I'm working off of my notebook here in Massachussetts. Needless to say, it now needs repairing, so I had best go read the man page on repairing. sleipnir:/coda/robert/private/coda/3.0/bd> repair This repair tool can be used to manually repair server/server or local/global conflicts on files and directories. You will first need to do a ""beginrepair"" to start a repair session where messages about the nature of the conflict and the commands that should be used to repair the conflict will be displayed. Help message on individual commands can also be obtained by using the ""help"" facility. Finally, you can use the ""endrepair"" or ""quit"" to terminate the current repair session. repair > help See the Coda manual or repair.1 for help repair > beginrepair Pathname of object in conflict? []: config.log a local-global-conflict repair session started the conflict is cuased by a reintegration failure use the following commands to repair the conflict: checklocal listlocal preservelocal preservealllocal discardlocal discardalllocal setglobalview setmixedview setlocalview a list of local mutations is availabe in the .cml file in the coda spool directory repair > checklocal local mutation: store /coda/robert/private/coda/3.0/bd/config.log/local no conflict repair > listlocal local mutations are: Store /coda/robert/private/coda/3.0/bd/config.log/local (length = 0) repair > setmixedview repair-view unchanged for subtree rooted at /coda/robert/private/coda/3.0/bd/config.log repair > In another window: slipnir:/> cd /coda/robert/private/coda/3.0/bd/config.log sleipnir:/coda/robert/private/coda/3.0/bd/config.log> ls -l total 6 dr--r--r-- 2 root nobody 2048 Oct 25 12:39 ./ drwxr-xr-x 11 robert nobody 2048 Oct 23 16:32 ../ -rw-r--r-- 1 robert nobody 1562 Oct 23 16:32 global -rw-r--r-- 1 robert nobody 0 Oct 25 12:39 local sleipnir:/coda/robert/private/coda/3.0/bd/config.log> more global This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. configure:530: checking for mawk ..... sleipnir:/coda/robert/private/coda/3.0/bd/config.log> more local local: Operation timed out sleipnir:/coda/robert/private/coda/3.0/bd/config.log> Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ " anonymous 3 306 hoard walk defect new 1998-10-28T23:29:31Z-0500 2004-05-21T17:08:32Z-0400 "From: Subject: hoard walk Date: Wed, 28 Oct 1998 18:29:31 -0500 (EST) Once in a while, I get one of these: pioctl:Walk(1000): Interrupted system call Sometimes I Ctrl-Z hoard walk, and a few minutes later this happens, sometimes venus dies and this happens. I'm not sure if there is a real relationship, or whether it just spontaneously does :). 3.0-CURRENT of FreeBSD. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ " anonymous 3 307 new FreeBSD kernel code defect new 1998-10-29T03:59:23Z-0500 2004-05-21T17:08:32Z-0400 "From: Subject: new FreeBSD kernel code Date: Wed, 28 Oct 1998 22:59:23 -0500 (EST) Most things appear to behave nicely -- some strange Netscape behavior though. Just had Netscape freeze on me accessing a file in /coda: 382 robert -1 0 13356K 6284K coda_c 0:08 0.00% 0.00% navigator-4.07 robert 382 0.0 12.4 13356 5804 ?? S 10:54PM 0:08.00 /usr/local/lib/ne robert 383 0.0 3.2 10040 1480 ?? I 10:54PM 0:00.12 (dns helper) (nav No interesting log messages. Cannot kill netscape. " anonymous 3 324 Same server as the last one defect new 1998-11-16T03:32:12Z-0500 2004-05-21T17:08:36Z-0400 "From: Subject: Same server as the last one Date: Sun, 15 Nov 1998 22:32:12 -0500 (EST) I restarted the server, and then attempted to poke at the volume (p.suckier) and discovered a conflict. I started the repair tool and pointed it at the directory (/coda/p.suckier/coda), and on performing 'repairinc', the server puked: Assertion failed: 0, file ""../../../coda/coda-src/vice/srv.cc"", line 334 Sleeping forever. You may use gdb to attach to process 22007.22:27:06 VN_GetDir Handle for Vnode 0x5 Uniq 0x2 cnt 1 22:27:06 VN_GetDirHandle for Vnode 0x5 Uniq 0x2 cnt 2 22:27:06 VN_GetDirHandle for Vnode 0x5 Uniq 0x2 cnt 3 22:27:06 VN_GetDirHandle for Vnode 0x13 Uniq 0x6e6 cnt 1 22:27:06 ****** FILE SERVER INTERRUPTED BY SIGNAL 11 CODE 12 ****** 22:27:06 ****** Aborting outstanding transactions, stand by... 22:27:06 Uncommitted transactions: 0 22:27:06 Uncommitted transactions: 0 22:27:06 Becoming a zombie now ........ 22:27:06 You may use gdb to attach to 22007 gdb: [root@faust srv]# gdb codasrv 22007 GDB is free software and you are welcome to distribute copies of it under certain conditions; type ""show copying"" to see the conditions. There is absolutely no warranty for GDB; type ""show warranty"" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... /vice/srv/22007: No such file or directory. Attaching to program `/usr/local/sbin/codasrv', process 22007 Reading symbols from /usr/libexec/ld.so...done. Reading symbols from /usr/lib/libstdc++.so.2.0...done. Reading symbols from /usr/lib/libm.so.2.0...done. Reading symbols from /usr/lib/libc.so.3.0...done. 0x81b4903 in sigsuspend () (gdb) where #0 0x81b4903 in sigsuspend () #1 0x81b2f45 in sigpause () #2 0x81b2dd6 in sleep () #3 0xfa84b in coda_assert (pred=0x173d ""0"", file=0x171a ""../../../coda/coda-src/vice/srv.cc"", line=334) at ../../../coda/lib-src/base/coda_assert.c:62 #4 0x18f6 in zombie (sig=11, code=12, scp=0x450748c8) at ../../../coda/coda-src/vice/srv.cc:334 #5 0xefbfdfdc in ?? () #6 0xabf52 in FindVLE (dl=@0x27cb80, fid=0x45074970) at ../../../coda/coda-src/vol/vlist.cc:67 #7 0xabf7a in AddVLE (dl=@0x27cb80, fid=0x45074970) at ../../../coda/coda-src/vol/vlist.cc:74 #8 0x187c4 in getFids (flist=0x27cb80, name=0x283d30 """", vnode=1501976, unique=2637104) at ../../../coda/coda-src/vice/codaproc.cc:1931 #9 0xb12f2 in DIR_EnumerateDir (dhp=0x27c800, hookproc=0x1873c , hook=0x283d30) at ../../../coda/coda-src/dir/dirbody.c:878 #10 0xaff63 in DH_EnumerateDir (dh=0x16eb18, hookproc=0x1873c , hook=0x283d30) at ../../../coda/coda-src/dir/codadir.c:298 #11 0x185c1 in GetSubTree (fid=0x45074c70, volptr=0x211300, vlist=0x283d00) at ../../../coda/coda-src/vice/codaproc.cc:1876 #12 0x182e8 in GetRepairObjects (volptr=0x211300, ov=0x2a7480, vlist=0x283d00, repList=0x2aa000, repCount=26) at ../../../coda/coda-src/vice/codaproc.cc:1784 #13 0x15552 in ViceRepair (cid=9, Fid=0x45074e24, status=0x45074dc0, StoreId=0x45074db8, BD=0x0) at ../../../coda/coda-src/vice/codaproc.cc:643 #14 0x41a33 in _ViceRepair (_cid=9, _reqbuffer=0x28d800, _bd=0x0) at vice.server.c:8574 #15 0x4dd16 in srv_ExecuteRequest (_cid=9, _reqbuffer=0x28d800, _bd=0x0) at vice.server.c:17137 #16 0x312c in ServerLWP (Ident=0xefbfda60) at ../../../coda/coda-src/vice/srv.cc:674 #17 0xf82fe in Create_Process_Part2 () at ../../../coda/lib-src/mlwp/lwp.c:1109 #18 0xfa632 in savecontext () #19 0xca43d80 in ?? () (gdb) up #1 0x81b2f45 in sigpause () (gdb) up #2 0x81b2dd6 in sleep () (gdb) up #3 0xfa84b in coda_assert (pred=0x173d ""0"", file=0x171a ""../../../coda/coda-src/vice/srv.cc"", line=334) at ../../../coda/lib-src/base/coda_assert.c:62 62 sleep(1); Current language: auto; currently c (gdb) up #4 0x18f6 in zombie (sig=11, code=12, scp=0x450748c8) at ../../../coda/coda-src/vice/srv.cc:334 334 CODA_ASSERT(0); Current language: auto; currently c++ (gdb) up #5 0xefbfdfdc in ?? () (gdb) up #6 0xabf52 in FindVLE (dl=@0x27cb80, fid=0x45074970) at ../../../coda/coda-src/vol/vlist.cc:67 67 if (FID_EQ(&v->fid, fid)) return(v); (gdb) list 62 vle *FindVLE(dlist& dl, ViceFid *fid) 63 { 64 dlist_iterator next(dl); 65 vle *v; 66 while (v = (vle *)next()) 67 if (FID_EQ(&v->fid, fid)) return(v); 68 return(0); 69 } (gdb) inspect v $1 = (vle *) 0x1 This is probably a corrupted volume now, so I am going to purge it. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ " anonymous 3 303 fsobj:Kill too deadly defect new 1998-12-19T16:56:56Z-0500 2004-05-21T17:08:31Z-0400 "From: Subject: fsobj:Kill too deadly Date: Sat, 19 Dec 1998 11:56:56 -0500 (EST) While reorganizing the structure of the store operation, I found that fsobj::Kill is called when f.i. the store has failed. This essentialy disallows all access to the object, but there seems to be no consideration for the fact that there could be cml entries connected to the object. (hoard binding ARE correctly cleaned up in this routine). Jan " anonymous 3 315 volume removal bug defect new 1999-01-06T00:13:07Z-0500 2004-05-21T17:08:34Z-0400 "From: Subject: volume removal bug Date: Tue, 5 Jan 1999 19:13:07 -0500 (EST) Volume removal is not removing the recoverable volume log as far as I can tell. Needs to be fixed. " anonymous 3 323 cfs listcache defect new 1999-01-08T22:46:46Z-0500 2004-05-25T04:53:27Z-0400 "From: Subject: cfs listcache Date: Fri, 8 Jan 1999 17:46:46 -0500 (EST) during a disconnection, this lists the mountpoints very badly. This is due to the fact that the u.mtpoint field is NULL during disconnections. I question if this is intentional. - Peter - " anonymous 3 291 authentication problem with kerberos coda defect Coda developers new 1999-10-29T15:09:18Z-0400 2007-04-02T06:18:10Z-0400 "From: Subject: authentication problem with kerberos Date: Fri, 29 Oct 1999 11:09:18 -0400 Full_Name: Dr. Michael Rietz Version: 5.3.3 OS: linux 2.2.10 Submission from: extrietz.mppmu.mpg.de (134.107.10.10) Hi, I'm trying to get kerberos authentication working on a guest system in the states: kerberos it self is working fine and telnet, rsh, ftp with it is working fine... but every time I try to kclog I get the following error. username: rietz Date: Fri 10/29/99 15:43:53 In Krb5GetKeys() Invalid login (RPC2_NOTAUTHENTICATED (F)). The corresponding message from strace -f kauth2 -realm .... is: stat(""/usr/tmp/rc_host_0"", {st_mode=S_IFREG|0600, st_size=6, ...}) = 0 geteuid() = 0 open(""/usr/tmp/rc_host_0"", O_RDWR) = 4 read(4, ""\5\1"", 2) = 2 fstat(4, {st_mode=S_IFREG|0600, st_size=6, ...}) = 0 read(4, "",\1\0\0"", 4) = 4 lseek(4, 0, SEEK_CUR) = 6 read(4, """", 4) = 0 lseek(4, 6, SEEK_SET) = 6 stat(""/etc/krb5.conf"", {st_mode=S_IFREG|0644, st_size=1520, ...}) = 0 close(4) = 0 write(2, ""auth2: Wrong principal in reques""..., 57) = 57 sendto(3, ""\0\0\0\10\""\376\231\5\26\232[\377\0\250\0\0\0\0\0\24\0""..., 80, 0, {sin_family=AF_INET, sin_port=htons(1436), sin_addr=inet_addr(""192.168.250.1"")}, 16) = 80 time([941209128]) = 941209128 write(1, ""15:58:48 Authentication failed f""..., 79) = 79 Thanks in advance for any help Michael " anonymous 3 318 venus code dumps with invalid command line parameters defect new 2000-08-26T09:19:34Z-0400 2004-05-21T17:08:34Z-0400 "From: Subject: venus code dumps with invalid command line parameters Date: Sat, 26 Aug 2000 05:19:34 -0400 Full_Name: paul risenhoover Version: 5.3.8-1 OS: Linux Submission from: phat.r8x.net (63.75.98.242) It's not a big deal, but updateclnt, updatesrv, and venus all core dump when given a parameter NAME but not a required VALUE. Example: venus -d (no debug level) auth2 doens't seem to have this problem. I didn't check codasrv " anonymous 3 688 Replace per-volume vnode arrays defect new 2002-12-17T19:26:59Z-0500 2003-03-13T21:46:28Z-0500 "The per-volume vnode arrays have scalability problems. A singly replicated volume will experience RVM allocation failures around 240k vnodes. Doubly replicated limit is around 120k, and with 8 replicas we cannot put more than 30k files in a single volume. By turning the vnode arrays into hash buckets we should be able to remove this limit and resizing the number of buckets would only be necessary for performance tuning reasons." jaharkes 3 703 Linux ENOENT & ESTALE errors coda defect jaharkes assigned 2003-02-07T16:17:15Z-0500 2007-09-13T05:22:31Z-0400 "We're seeing ENOENT and ESTALE errors with 2.4 Linux kernels. The ESTALE is caused by an NFS close-to-open patch that went into 2.4.18 or .19, which bugs out when '.' or '..' is opened, but the dentry revalidation test fails. First of all the test is too generic, so any filename starting with '.' will receive the additional test. Second, they are revalidating the path instead of the object, I don't see how they would handle a rename from a different client correctly, as the current test 'reinstates' the old pathname in the dcache. The NFS-close-to-open semantics really should be using inode_revalidate, which would fix the Coda problems wrt ESTALE errors. The ENOENT failure is triggered by concurrent directory lookups when the second thread finds a cached dentry in real_lookup after blocking on the i_sem. Ultimately both cases are caused by Coda's 'volatile' pathnames, these are used for mountpoints and repair subtrees to make it easier to turn symlinks into directories and vv. Jan " jaharkes 3 715 Use of C++ objects in RVM defect jaharkes assigned 2003-03-10T18:21:46Z-0500 2003-03-13T22:09:01Z-0500 "The use of C++ objects in RVM should be avoided as much as possible. Their layout/implementation could change when the compiler, compiler options (-march) or libstdc++ changes." jaharkes 3 716 vice/misc/Update*Log are not rotated coda defect Coda developers new 2003-03-11T15:39:27Z-0500 2007-04-02T06:19:23Z-0400 Subj anonymous 3 892 The Death of Venus, can't checkpoint. defect new 2004-07-03T03:39:03Z-0400 2004-07-03T03:39:10Z-0400 "I get this during checkpointing my Mail directory. 21:33:42 Checkpointing h:u:aredridel 21:33:42 to /usr/coda/spool/500/theinternetco.net_h_u_aredridel.tar 21:33:42 and /usr/coda/spool/500/theinternetco.net_h_u_aredridel.cml 21:33:42 can't checkpoint (/Maildir/..ibex.index), no data 21:33:42 can't checkpoint (/Maildir/.ibex.index), no data 21:33:42 can't checkpoint (/Maildir/.ibex.index.data), no data 21:33:42 can't checkpoint (/Maildir/..ibex.index.data), no data 21:33:42 Reintegrate: h:u:aredridel, 6/6 records, result = Invalid argument 21:35:25 fatal error -- Assertion failed: file ""fso_cfscalls2.cc"", line 284 21:35:26 RecovTerminate: clean shutdown " anonymous 3 922 What ?! no more than 1024 vol total??? defect new 2004-09-17T12:04:42Z-0400 2004-09-17T12:04:43Z-0400 "realy?? I need 4096 volumes on a single scm, but only 1024 created, anyone met this? It seems mostly related with RVM . But to mod the source is is a unbeliveable dream....... hope anybody could " anonymous 3 1591 a bug in auth2/pwsupport.c defect new 2006-08-25T10:48:45Z-0400 2006-08-25T10:51:19Z-0400 "The lines shown below can (and eventually will) lead to accessing wrong places in memory with sufficiently big ids (over 2^30) when doubling yields negative numbers: grep -n EnlargePW auth2/pwsupport.c ... 230: EnlargePW(2*thisid); ... 273: if (vId >= PWLen) EnlargePW(2*vId); Another and more evident problem with code in pwsupport.c is allocating an array up to max id in size, which easily leads to huge memory consumption, depending on id allocation. On some systems memory is allocated at malloc() time, not at access time (like Linux?). What about disallowing arbitrary id allocation at all? Preferably stopping to expose them to the users, of course. That would solve or drastically reduce the problems above, and also will remove the tempting and harmful ""possibility"" of synchronizing Coda ids with client side Unix ids. Otherwise the pwsupport.c memory allocation should be redone. Different sites have different policies of uid allocation on Unix and they can easily try to explicitely allocate Coda uids as well. " anonymous 3 1593 Concurrent open & remove deadlock defect new 2006-10-05T22:02:06Z-0400 2006-10-05T22:02:06Z-0400 "I had one client reading a maildir mailbox, while another client was removing about 2/3rd of the files. The reading client got stuck on a GetAttr that kept retrying indefinitely. This may be a hard to track race. Jan " jaharkes 3 1620 freebsd kernel module memory leak kernel/freebsd defect Coda developers new 2007-07-17T15:17:49Z-0400 2007-07-17T15:17:49Z-0400 "When unloading the Coda kernel module we leak memory (4 allocations, 13824 bytes)" jaharkes 3 1625 improper access rights evaluation coda/server defect Coda developers new 2007-08-24T14:41:51Z-0400 2008-10-17T15:17:03Z-0400 "The interpretation of access bits makes 'l' bit useless. It is impossible to have traverseable directories with unreadable files, which otherwise is useful. The expected behaviour <=> current behaviour: 'l' should allow fetching the contents of the directory <=> does not, 'r' is needed on both parent and the directory itself 'r' should not be necessary to fetch child directories, they have their own 'l' bits which are sufficient and at a proper place for controlling the access <=> 'r' is necessary to fetch child directories This apparently does not make a good use of the available control possibilities and also contradicts documentation (does not look to me like having any reason to be this way either). Thanks for an excellent file system - which makes such issues even more regretful! Should be fairly easy to fix?" u+codalist-p4pg@… 3 1631 replicas differ without conflicts coda defect Coda developers new 2007-09-22T07:42:30Z-0400 2008-02-08T20:49:36Z-0500 "A double-replicated directory had acls A a B b C c then some time the acls were changed to X x Y y Z z from a ~6.9.2 Linux client. Now one of the replicas shows acls as X x Y y Z z while the other one shows X x A a B b C c i.e. like half-done changes. With other words, different clients (picking one or another server) get different results without seeing any conflict. cfs expand shows the reason. The servers are connected by a slow unreliable line, this fact may have helped to trigger some race in resolution s that no conflict was detected nor resolved. " u+codalist-p4pg@… 3 1632 auth2 daemon should behave the same on invalid password and invalid account name coda/server defect Coda developers new 2007-10-02T06:11:22Z-0400 2008-01-24T11:50:34Z-0500 To prevent account name guessing attacks. anonymous 3 1633 Coda does not work on FreeBSD7/amd64 coda defect Coda developers new 2007-11-01T21:06:41Z-0400 2007-11-01T21:06:41Z-0400 "I installed CODA via the ports (version 6.9.1) on my FreeBSD7-BETA1 amd64 machine. When I try to cd into /coda the following happens brauer# cd /coda [[BR]] /coda: Unknown error: 158. if I try to clog into testserver.coda.cs.cmu.edu the result is ""Local login only, could not contact venus"". The syslog complains (?) about a sign extension WARNING pid 58053 (clog): ioctl sign-extension ioctl ffffffff80245603 I tried to debug this on my own, but I think I'm pretty much lost. I know that this has to do with ioctl or pioctl respectively. " coda@… 3 1635 Possibly unnecessary resolutions/conflicts coda defect Coda developers new 2008-01-21T15:45:39Z-0500 2008-01-21T15:45:39Z-0500 "When a client writes to a file and the update is applied on a subset of the available servers, the client will queue a COP2 message. If before we send the COP2, another client discovers and resolves the conflict, even if we receive a callback the COP2 is still sent. As a result we may simply reinstate the conflict and if 2 servers are involved may even create an unrepairable one. Have to check how the server handles the COP2 it received after resolution (checks store-id, cop pending queues?)." jaharkes 3 1641 Matriculating thread not woken up when we detect a conflict. coda defect Coda developers new 2008-02-13T13:13:14Z-0500 2008-02-13T13:13:14Z-0500 When a getattr is in progress and a second request for the same file comes in it is blocked until the first operation completes (matriculating). I have reason to believe that when the active RPC returns a fatal error (EINCONS/ENOENT?) and we fail to get valid status information we never wake up any matriculating threads. jaharkes 3 1612 Add revisioning coda enhancement Coda developers new 2007-06-30T13:58:39Z-0400 2007-07-03T09:38:23Z-0400 "Distributed + revisioning file system, that's a real miss for group work.... And could also partially solve conflicts between multiple offline file changes, keeping all of them as different file versions. Something like Wayback filesystem on top of coda filesystem, maybe. " anonymous 3 312 Cfs manpage needs update coda Coda-6.9.0 Coda-7.0.0 defect Coda developers new 1999-07-14T14:17:31Z-0400 2007-05-12T21:20:41Z-0400 "From: Subject: Cfs manpage needs update Date: Wed, 14 Jul 1999 10:17:31 -0400 The cfs manpage needs to be updated for the 'sq' (setquota) argument. Jan ---- Forwarded message from ""LEE, Yui-wah (Clement)"" --- Subject: Re: (re)setting quotas in Coda To: codalist@TELEMANN.CODA.CS.CMU.EDU Date: Wed, 14 Jul 1999 10:22:46 +0800 (CST) Reply-To: clement@cse.cuhk.edu.hk (LEE, Yui-wah (Clement)) From: clement+@cs.cmu.edu (LEE, Yui-wah (Clement)) Resent-From: codalist@TELEMANN.coda.cs.cmu.edu Paul A. Cheshire wrote: > On Fri, 02 Jul 1999, LEE, Yui-wah (Clement wrote: > > Peter Braam wrote: > > > volutil will help. Man volutil should tell you how to do it. > > > > Sorry, I may have missed something. Can you tell me which command > > of volutil can set volume quota ? I took a quick look at ""man volutil"" > > (of Coda 5.2.0) but could not find the command. > > > > Thanks! > > > > -- Clement > > Actually, I have just found it - it's a cfs parameter (cfs sq) Oh, thank you. ""man cfs"" does not seem to show the command, but ""cfs help"" does show it. Thanks. -- Clement ----- End forwarded message ----- " anonymous 3 724 Reintegration and version vectors coda Coda-7.0.0 defect Coda developers new 2003-03-17T16:01:48Z-0500 2007-04-02T06:17:03Z-0400 "It seems that the client is not correctly predicting the version vector following a successful reintegration. This is causing a lot of unnecessary fetches of unmodified data. A clear indication of the problem is that fact that validateattrs fails for every reintegrated object after a disconnection. Was this done intentionally to make sure that the client cache matches the state on the server after reintegration by basically forcing the client's copies to be invalid? Jan " jaharkes 3 1610 preservelocal broken for store operations coda/client Coda-7.0.0 defect Coda developers new 2007-05-12T13:27:31Z-0400 2007-05-12T13:27:31Z-0400 cfs preservelocal cannot repair a store operation because the code fetches up to date attributed from one of the replicas, copies the data to the updated object and tries to reintegrate. However the replica doesn't have a CML, so the reintegration fails. jaharkes 3 1654 "an unusual kind of ""unneeded"" conflicts" coda Undefined defect Coda developers new 2008-07-17T13:37:03Z-0400 2008-09-30T08:05:54Z-0400 "Running a single Coda server with code from 2007-11-07 (Nov 07) on a 64-bit AMD Linux and about 380 clients with Coda 6.9.3 on 32-bit Intel-compatible Linux. Each client is assigned a randomly chosen number between 0 and 59 and makes ""touch"" on a file on Coda once an hour, the assigned number of minutes from the beginning of the hour, all clients hence averaging together ~6.3 updates at the beginning of each minute. The file is located in a client-specific directory, so that no host ever updates files in another host's directory. Unfortunately, all these ~380 directories are placed on a single volume. Once in a while, the file to be updated becomes a dangling symlink, indicating a conflict. There is apparently no reason for local-global conflicts, nor any possibility for server-server conflicts, as there is only a single server. The conflicts seem to be local-global (?). Unexpectedly, each of these ""conflicts"" can be seen on any host. ""cfs br"" expands the symlink into a directory, containing a directory corresponding to the server's fqdn, and a dangling symlink named .localcache, which looks like a conflict itself (? writing from memory, no conflicts to cut-n-paste right now). The conflicts can be reliably removed with ""removeinc"" either on the corresponding host or via another client. The conflicts are very annoying and their presense seems to be totally unreasonable. They appear irregularly, with a frequency of about a dozen a day. Their appearance may be triggered when the server host gets some extra load or when a script iterates reading the directories, collecting the timestamps and other status-like information - but this is just a guess. I am not aware of any way to reproduce the conflicts besides waiting, but they reappear with certainty. An regrettable setup feature is that the server host sometimes acts as a client as well, though strictly readonly while accessing the mentioned directories." u-wk5r 3 1656 Reintegration ignores local-global conflicts coda Undefined defect Coda developers new 2008-08-27T13:51:30Z-0400 2008-08-27T14:22:52Z-0400 "Noticed a venus process was continuing reintegration even though it indicated that there was a server-server conflict. {{{ [ I(469) : 0352 : 13:11:26 ] vproc::Begin_VFS(Reintegrate): vid = 2.7f000626, u.u_vol = 51eb6ac8, mode = -1 [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::GetReintegrateable: (..., -31546) 4 records, 15000 msec remaining [ I(469) : 0352 : 13:11:26 ] volent::IncReintegrate: (..., -31546) uid = 1000 [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncReallocFids: (...) and tid = -31546 [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncReallocFids: (...) [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncThread: (...) tid = -31546 ClientModifyLog: owner = 1000, count = 3856 current stats: 768 183.0 206048.4 3088 783.8 cancelled stats: 0 0.0 0.0 0 0.0 Utimes : sid = (c1716461.-2147401352), time = 1219856461, uid = 1000 tid = -31546 bytes = 244 pred = (0, 0), succ = (0, 0) to_be_repaired = 0 frozen = 1, cancel = 0, failed = 0, committed = 0 fid = 2.7f000626.1114.fa1c, utimes = 1079304815 vv = [ 0 2 0 0 0 0 0 0 ] [ -1049533343 -2147401353 ] [ 0 ] Chmod : sid = (c1716461.-2147401351), time = 1219856461, uid = 1000 tid = -31546 bytes = 244 pred = (0, 0), succ = (0, 0) to_be_repaired = 0 frozen = 1, cancel = 0, failed = 0, committed = 0 fid = 2.7f000626.1114.fa1c, chmod = 664 vv = [ 0 2 0 0 0 0 0 0 ] [ -1049533343 -2147401352 ] [ 0 ] Rename : sid = (c1716461.-2147401350), time = 1219856461, uid = 1000 tid = -31546 bytes = 276 pred = (0, 0), succ = (0, 0) to_be_repaired = 0 frozen = 1, cancel = 0, failed = 0, committed = 0 spfid = 2.7f000626.56cd.f575, sname = (.d1090007.jpg.9FRrDG) tpfid = 2.7f000626.56cd.f575, tname = (d1090007.jpg) sfid = 2.7f000626.1114.fa1c spvv = [ 1 873 0 0 0 0 0 0 ] [ -1049533343 -2147401354 ] [ 0 ] tpvv = [ 0 0 0 0 0 0 0 0 ] [ 0 0 ] [ 0 ] svv = [ 0 2 0 0 0 0 0 0 ] [ -1049533343 -2147401351 ] [ 0 ] Create : sid = (c1716461.-2147401349), time = 1219856461, uid = 1000 tid = -31546 bytes = 270 pred = (0, 0), succ = (0, 0) to_be_repaired = 0 frozen = 1, cancel = 0, failed = 0, committed = 0 pfid = 2.7f000626.56cd.f575, name = (.d1090007.sized.jpg.7tTrf2) cfid = 2.7f000626.111c.fa1e, mode = 600 pvv = [ 1 873 0 0 0 0 0 0 ] [ -1049533343 -2147401350 ] [ 0 ] [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncThread: (...) [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncPack: (...) and tid = -31546 [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncPack: (...) [ I(469) : 0352 : 13:11:26 ] vsgent::GetMgrp 0x8e11410 1000 1 [ I(469) : 0352 : 13:11:26 ] mgrpent::GetHostSet: 0x8dae2d0, uid = 1000, mid = 16 [ I(469) : 0352 : 13:11:26 ] volent::FlushCOP2(Piggy): vol = 7f000626 [ I(469) : 0352 : 13:11:26 ] WAITING(CommQueue) pri = 1, for 1 at pri 2 [ I(469) : 0352 : 13:11:26 ] (Multi)Reintegrate: code = -2001, elapsed = 3.3 [ I(469) : 0352 : 13:11:26 ] mgrpent::CheckCOP1: acode = -2001 hosts = [0x48da0280 0x49da0280 0 0 0 0 0 0], retcodes = [602 0 -2002 -2002 -2002 -2002 -2002 -2002] [ I(469) : 0352 : 13:11:26 ] RecoverPathName: fid = 2.7f000626.1114.fa1c [ I(469) : 0352 : 13:11:26 ] fsobj::GetPath (1.ff000001.1.1): venusRoot. [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::MarkFailedMLE: failed reintegrating: setattr /coda/coda.cs.cmu.edu/... [ I(469) : 0352 : 13:11:26 ] fsobj::GetPath (1.ff000001.1.1): venusRoot. [ I(469) : 0352 : 13:11:26 ] k_Purge: fid = (2.7f000626.1114.fa1c), severely = 0 [ I(469) : 0352 : 13:11:26 ] k_Purge: CODA_ZAPFILE, returns 0 [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::MarkFailedMLE: /coda/coda.cs.cmu.edu/... now in local/global conflict [ 0 0 0 0 0 0 0 0 ] [ 0.0 ] [ 0 ] volent::CollateVCB: Version stamps returned: 210 0 volent::CollateVCB: Callback status returned: 1 0 [ I(469) : 0352 : 13:11:26 ] ViceReintegrate: transferred 496 bytes [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::COP1: (replica 0) 0 stale dirs [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::COP1: (replica 1) 0 stale dirs [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::COP1: (...), 496 bytes, returns 0, index = 0 [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncCommit: (...) tid = -31546 [ I(469) : 0352 : 13:11:26 ] cmlent::commit: (-31546) [ I(469) : 0352 : 13:11:26 ] fsobj::FinalCmlent: 2.7f000626.1114.fa1c [ I(469) : 0352 : 13:11:26 ] cmlent::commit: Add COP2 with sid = 0xc1716461.80014178 [ I(469) : 0352 : 13:11:26 ] cop2ent::operator new() [ I(469) : 0352 : 13:11:26 ] cop2ent::cop2ent() [ I(469) : 0352 : 13:11:26 ] cmlent::~cmlent: tid = (c1716461.-2147401352), uid = 1000, op = Utimes [ I(469) : 0352 : 13:11:26 ] cmlent::operator delete() [ I(469) : 0352 : 13:11:26 ] cmlent::commit: (-31546) [ I(469) : 0352 : 13:11:26 ] fsobj::FinalCmlent: 2.7f000626.1114.fa1c [ I(469) : 0352 : 13:11:26 ] cmlent::commit: Add COP2 with sid = 0xc1716461.80014179 [ I(469) : 0352 : 13:11:26 ] cop2ent::operator new() [ I(469) : 0352 : 13:11:26 ] cop2ent::cop2ent() [ I(469) : 0352 : 13:11:26 ] cmlent::~cmlent: tid = (c1716461.-2147401351), uid = 1000, op = Chmod [ I(469) : 0352 : 13:11:26 ] cmlent::operator delete() [ I(469) : 0352 : 13:11:26 ] cmlent::commit: (-31546) [ I(469) : 0352 : 13:11:26 ] fsobj::FinalCmlent: 2.7f000626.56cd.f575 [ I(469) : 0352 : 13:11:26 ] fsobj::FinalCmlent: 2.7f000626.1114.fa1c [ I(469) : 0352 : 13:11:26 ] cmlent::commit: FinalCmlent for 2.7f000626.1114.fa1c [ I(469) : 0352 : 13:11:26 ] fsobj::FinalCmlent: 2.7f000626.56cd.f575 [ I(469) : 0352 : 13:11:26 ] cmlent::commit: Add COP2 with sid = 0xc1716461.8001417a [ I(469) : 0352 : 13:11:26 ] cop2ent::operator new() [ I(469) : 0352 : 13:11:26 ] cop2ent::cop2ent() [ I(469) : 0352 : 13:11:26 ] cmlent::~cmlent: tid = (c1716461.-2147401350), uid = 1000, op = Rename [ I(469) : 0352 : 13:11:26 ] fsobj::MakeClean: (2.7f000626.1114.fa1c) [ I(469) : 0352 : 13:11:26 ] cmlent::operator delete() [ I(469) : 0352 : 13:11:26 ] cmlent::commit: (-31546) [ I(469) : 0352 : 13:11:26 ] fsobj::FinalCmlent: 2.7f000626.56cd.f575 [ I(469) : 0352 : 13:11:26 ] cmlent::commit: FinalCmlent for 2.7f000626.56cd.f575 [ I(469) : 0352 : 13:11:26 ] fsobj::FinalCmlent: 2.7f000626.111c.fa1e [ I(469) : 0352 : 13:11:26 ] cmlent::commit: FinalCmlent for 2.7f000626.111c.fa1e [ I(469) : 0352 : 13:11:26 ] cmlent::commit: Add COP2 with sid = 0xc1716461.8001417b [ I(469) : 0352 : 13:11:26 ] cop2ent::operator new() [ I(469) : 0352 : 13:11:26 ] cop2ent::cop2ent() [ I(469) : 0352 : 13:11:26 ] cmlent::~cmlent: tid = (c1716461.-2147401349), uid = 1000, op = Create [ I(469) : 0352 : 13:11:26 ] cmlent::operator delete() [ I(469) : 0352 : 13:11:26 ] repvol::FlushCOP2: vol = 7f000626, window = 0 [ I(469) : 0352 : 13:11:26 ] ClientModifyLog::IncCommit: (...) [ I(469) : 0352 : 13:11:26 ] volent::IncReintegrate: committed [ I(469) : 0352 : 13:11:26 ] IncReintegrate: (...,-31546) result = SUCCESS, elapsed = 15.2 (4.0, 8.8, 2.3) [ I(469) : 0352 : 13:11:26 ] old stats = [0, 4, 0, 0, 0] [ I(469) : 0352 : 13:11:26 ] new stats = [ 0, 0.0, 0.0, 4, 1.0], [ 0, 0.0, 0.0, 0, 0.0] }}}" jaharkes 3 1659 utime fails on symlinks coda Undefined defect Coda developers new 2008-10-01T17:38:14Z-0400 2008-10-01T17:39:43Z-0400 rsync complains because it fails to set the ctime/mtime on dangling symlinks. jaharkes 3 1660 coda_fts seems to be broken? coda Undefined defect Coda developers new 2008-11-12T04:36:34Z-0500 2008-11-12T04:36:34Z-0500 "mklka compiled with uclibc which lacks fts_ functions produces unusable lka-databases, the paths returned by fts_read() seem to contain zero bytes instead of '/' in all corresponding positions below one level under the scanning top directory. Our workaround was to rewrite mklka to use ftw() which works fine. If coda_fts is used anywhere else, it should be fixed, otherwise nftw() interface is pretty much sufficient for mklka purposes (nftw() is available in uclibc, on the other side it is slightly tricky to use it, its declaration in ftw.h depends on __USE_XOPEN_EXTENDED). Rune L" rl 3 1661 dev package dependencies coda Undefined defect Coda developers new 2008-12-15T13:06:30Z-0500 2008-12-15T13:06:30Z-0500 librpc2-dev and librvm-dev should depend on liblwp-dev jaharkes 3 1662 parallel traversal of symlinks is still broken on Linux 2.6 coda Undefined defect Coda developers new 2008-12-29T03:52:38Z-0500 2008-12-29T03:52:38Z-0500 "Found an old test script from 2006 which still reliably triggers errors with recent Coda and kernels. Most probably this is a known issue but attaching the script for reference anyway. Rune" rl 3 1664 purgevol_rep fails when volume name contains '/' coda Undefined defect Coda developers new 2009-01-22T17:35:22Z-0500 2009-01-22T17:38:48Z-0500 Some of the sed rules in the script get confused. Unfortunate considering that '/' characters are recommended usage in some cases. jaharkes 3 1666 rename get_tid rvm Undefined defect jaharkes assigned 2009-02-06T14:57:41Z-0500 2009-02-16T17:17:13Z-0500 rvm's get_tid function should be renamed, a name collision causes transactions to fail. jaharkes 3 1668 lookaside may use stale hash which leads to permanently stale data coda Undefined defect Coda developers reopened 2009-05-17T03:17:50Z-0400 2009-05-20T02:05:42Z-0400 "if a Coda file is present in the lookaside storage, then updated ""in place"" on Coda while the client is down (possibly in other cases too, but this is what I observed), then the file contents is later refetched from lookaside according to the _old_ hash. There seems to be no way to purge the wrong contents, ""cfs fl file"" leads to a repeating copy of the stale data, ""cfs fl dir"" refuses to purge as the directory is ""active"" (I do not see it being used by any process), ""cfs flushvolume"" does not help either. Client restart does not help. Clent reinit helps. Easily visible by doing ""cfs expand ..../file"" ""md5sum ..../file/*"" Local cache shows the old sum while the server replicas show the new one. Observed on two clients with Coda 6.9.4, on Linux 2.6.28 and 2.4.26." u-wk5r 3 1669 Venus hangs indefinitely if any of the servers it knows about is busy coda Coda-6.9.4 Undefined defect Coda developers new 2009-07-10T05:54:27Z-0400 2009-07-30T05:12:49Z-0400 "Venus thread for server polling gets stuck when one of the servers is busy, as there is no ""being busy"" timeout (which otherwise would be a desirable feature). According to comments in venus/comm.h: * The CommQueue summarizes outstanding RPC traffic for all threads. * Threads servicing requests defer to higher priority threads before * using the network. Note that Venus cannot determine the location of a * network bottleneck. Therefore, it conservatively assumes that all * high priority requests are sources of interference. That is, the waiting condition seems to be interpreted as network congestion. As a result, other threads, like hoarding and reintegration, get stuck waiting for the higher priority server probe thread. This makes clients extremely vulnerable to a single server being busy or deliberately unfriendly. I wonder whether such blocked threads may consequently cause a server to wait for a client, the client possibly indicating a ""busy"" state and thus creating a possibility for a deadlock. Mere reduction of the server probe thread priority may eliminate the main cause of the contention. This might be inadequate for server probing under real network congestion and insufficient to fully avoid client-server reciprocal locking, but worth consideration. The proposed patch is attached." u-codatrac-200907@… 3 1670 LSB tags in debian init scripts coda Undefined defect Coda developers new 2009-11-20T15:33:28Z-0500 2009-11-20T15:33:28Z-0500 Debian is changing boot sequence ordering and the Coda init scripts are outdated and do not include the necessary tags. jaharkes 3 1671 Crash in umount coda Undefined defect Coda developers new 2009-11-20T15:36:41Z-0500 2009-11-20T15:36:41Z-0500 Noticed two machines had unclean shutdown, dcache panic during unmount. Maybe related to an active reference to a file in Coda. jaharkes 3 1650 Fedora specific (LSB?) initscripts for coda coda Undefined enhancement Coda developers new 2008-05-22T01:17:13Z-0400 2008-05-29T16:03:33Z-0400 "Hi, Short intro: I'm a Fedora developer and I've recently packaged coda for Fedora. During packaging I noticed that coda's sysv style initscripts are somewhat archaic, they miss many new LSB mandatory commands like status, do not have LSB exit codes on failure, and they do not have colored status messages. Thus I've created initscripts for Fedora which are LSB compliant, they use shell functions from /etc/init.d/functions, and I don't know how distyro specific these are. Another change I've made is that I use killproc instead of volutil shutdown to shutdown the codasrv process, as killproc will wait till the process is actually no more (and issue a kill -9 after a configurable timeout). For this purpose I've added a sigterm handler which sets the Shutdown flag, just like the volutil shutdown rpc call does). Then I noticed that shutdown takes up to 30 seconds to commence, due to using a polling thread for this. I've fixed this by using LWP_QWait and LWP_QSignal instead. I'll attach the initscripts and the sigterm+nopoll patch here. " jwrdegoede 4 1614 Add support for CODA_OPEN_BY_FH kernel/freebsd enhancement Coda developers new 2007-07-11T21:03:20Z-0400 2007-07-12T10:09:47Z-0400 FreeBSD has a way to refer to file objects through an opaque file handle, which can most likely be obtained in userspace with the fhopen syscall. We can simplify the downcall handling path in the kernel module if venus can return such an opaque file handle. jaharkes 4 1615 Error message when open of cfs0 fails coda/client enhancement Coda developers new 2007-07-12T10:09:16Z-0400 2007-07-12T10:09:16Z-0400 "When we fail to open /dev/cfs0 it may be that another venus process is running, but it could also be that the kernel module hasn't been loaded yet. The current error message only handles the first case and is confusing when the kernel module is not yet loaded." jaharkes 4 1598 rewrite multirpc to use stub generated marshalling/unmarshalling rpc2 Undefined enhancement Coda developers new 2007-02-20T15:30:54Z-0500 2007-04-06T03:43:55Z-0400 "Normal rpc2 packing/unpacking functions are generated by the rp2gen stub generator. However MultiRPC2 messages, and the Coda client/server reintegration log, are packed at run time. This is flexible, but * packing/unpacking bugs have to be fixed in up to 6 different places (rp2gen, multirpc pack, multirpc unpack, venus cml packing and codasrv cml unpacking). * the code uses variable length argument lists (stdarg) so we don't get compile-time type checking. * there is a lot of copying/dereferencing going on because it isn't always clear what data type is expected to be passed to the pack or returned from the unpack function. * we could probably share a lot of code with (and between) the rp2gen generated stubs which would reduce the size of the Coda binaries. * currently the CML pack/unpack functions are using undocumented (and unexported) insides from MultiRPC. However consistently changing this will propagate a lot of changes to the Coda codebase, so we'll have to bump the major version. " jaharkes 5 1622 gcodacon: missing manpage coda/client Coda-6.9.2 Coda-7.0.0 enhancement Coda developers new 2007-08-04T12:11:58Z-0400 2007-12-29T23:31:18Z-0500 Should add a man page for gcodacon jaharkes 5 623 MaxRetries exceeded...returning EWOULDBLOCK coda/client Undefined defect Coda developers new 1997-07-18T02:51:27Z-0400 2007-04-06T03:43:43Z-0400 "From: Subject: MaxRetries exceeded...returning EWOULDBLOCK Date: Thu, 17 Jul 1997 22:51:27 -0400 1. My Venus (i386_nbsd1 March 18) vanished because the hoard daemon doesn't like ENOSPC. 2. I couldn't restart Venus because umount -> EINVAL. 3. I rebooted. 4. I tried to restart my huge make job, but it ran into some weird problem with a .depend file: 22:30:46 MaxRetries exceeded...returning EWOULDBLOCK 22:30:46 MaxRetries exceeded...returning EWOULDBLOCK 22:30:50 Volume u.davide.kernel busy, waiting 22:31:14 Volume u.davide.kernel busy, waiting 22:31:39 Volume u.davide.kernel busy, waiting 22:32:04 Volume u.davide.kernel busy, waiting 22:32:29 Volume u.davide.kernel busy, waiting 22:32:54 Volume u.davide.kernel busy, waiting 22:33:19 Volume u.davide.kernel busy, waiting 22:33:39 Volume u.davide.kernel busy, waiting 22:34:00 Volume u.davide.kernel busy, waiting 22:34:12 MaxRetries exceeded...returning EWOULDBLOCK 22:34:21 Volume u.davide.kernel busy, waiting 22:34:42 MaxWouldBlock exceeded...returning EWOULDBLOCK 22:34:42 Volume u.davide.kernel busy, waiting 22:35:06 Volume u.davide.kernel busy, waiting 22:35:27 Volume u.davide.kernel busy, waiting 22:35:52 Volume u.davide.kernel busy, waiting 22:36:17 Volume u.davide.kernel busy, waiting 22:36:42 Volume u.davide.kernel busy, waiting 5. Eventually, by dumb luck, I realized that I had forgotten to clog. Boom, everything's fine, resolve works, I'm back in business. I think a better error message here would be nice. Details in /coda/project/coda/bugs/piper-EWOULDBLOCK.log.gz (look for "".depend""). Dave " anonymous 5 1590 CODA_SYMLINK requires extra lookup kernel Undefined enhancement Coda developers new 2006-08-12T00:45:04Z-0400 2007-04-06T03:43:33Z-0400 "The CODA_SYMLINK and CODA_LINK upcalls don't return the fid of the newly created fso. This forces the various kernel modules to perform an extra lookup (and possibly getattr). It is probably useful to add new upcalls that include any missing information we may need to create the in-kernel vnode/inode object. CODA_CREATE and CODA_MKDIR return both the fid and the attributes. " jaharkes 5 863 Problem with Linux kernel coda.h kernel Undefined task Coda developers new 2004-03-30T19:42:42Z-0500 2007-04-06T03:43:21Z-0400 "This problem exists in the coda.h file included with the Linux kernel. I have checked and I know the problem exists in 2.6.1 and 2.6.4. When using coda.h from an external application, the include conflicts with the inclusion of many standard include files, including but not limited to . Including instead seems to mostly correct the issue. I suspect there needs to be some rearranging with all those #ifdefs, though I'm not sure what exactly needs to be done. There's also an issue related to these dirent lines: bits/dirent.h: #define d_fileno d_ino dirent.h: #define d_ino d_fileno If linux/coda.h is included before other includes, there is a compile error reporting that no d_ino field exists. If it is included after other includes, no such error exists. " anonymous