(Illustration by Gaich Muramatsu)
Hello, I've been reading through the archive of this list the past few days while setting up my coda server & client. It has been very helpful so far but I have been unable to find a good solution for my current problem. It seem so matter what I do when I start populating my volume with data I develop local inconsistent objects. Assuming I star rsyncing directory A the inconsistent object is always in the same place. If I rsync from location B I also develop an inconsistent object. I have not calculated to see if the same amount of data is transfered before the inconsistent object forms. My configuration is very straight forward 1 server and 1 client. I have a large RVM file (1G). I am running version 5.3.20 built from the debian packages under debian/stable. The two machines are connected via 100baseT. The server has two cpus and 1 gig of ram so it should be able to handle 1G RVM with out any problems. When the inconsistent object is first reported I can see that it is a symlink along the lines of: summary -> @7f000003.00000515.00001a1b (note. this is not the true value) After leaving the /coda directory and reentering it to the location of the inconsistent object I see: lrw-r--r-- 1 root nogroup 27 Apr 17 13:47 global -> @7f000003.00000515.00001a1b drwxr-xr-x 3 507 nogroup 2048 Apr 17 13:45 local summary is a directory. Trying to repair it yields: Could not allocate new repvol: Object not in conflict beginrepair failed. The only thing I have found to make the client reconnect to the server is a ./venus -init. I'd like to get to the bottom of this. This will become part of a web cluster which needs to update files and propagate the changes. I found this while looking through the list, could my log size be a problem? I'm trying to move several gigs of data into my volume. > volutil -h cluster3 setlogparms 3000002 reson 4 logsize 16384 I also see these messages in my venus logs, don't suppose I can repair the local substrees with begingrepair bailing out on me? I'm hoping I'm just passing the wrong argument to beginrepair. HDBDaemon about to sleep on hdbdaemon_sync 14:20:23 volume PHALANX has unrepaired local subtree(s), skip checkpointing CML! Well thanks for any answerers or suggestions. I hope I can make this work, else I'll be stuck in the same boat before I found coda. Regards, matthias -- Matthias Halfmann (Voxel Dot Net, Inc) halfmm_at_voxel.net (518) 330 7593Received on 2003-04-17 14:29:44