Coda File System

Very frequent - 'Local inconsistent object'

From: Matthias Halfmann <halfmm_at_voxel.net>
Date: Thu, 17 Apr 2003 14:26:33 -0400 (EDT)
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 7593
Received on 2003-04-17 14:29:44