Coda File System

Simple problem... I think

From: Samir Patel <samir_at_eden.rutgers.edu>
Date: Tue, 15 Apr 2003 15:51:35 -0400 (EDT)
Hey all,

I've been playing around with CODA for the past couple weeks.  I've
got a server setup with two clients running linux.  Everything appears
to be fine and dandy until there's a consistency failure.  Here's what
I do:

1) clog into the clients using the same id

2) On client1, I create a file with the 'cat > blah' command... and
just enter garbage into the file.

3) On client2, I delete the file that is still in the process of being
created by client1.

4) I close the created file on client1.  It now shows up as something
like:

blah -> @7f000000.00001421.000007c3

when I do an 'ls -l' on it.


5) I attempt a repair... but get messages like this:

# 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 > beginrepair blah
Too few directory entries
Could not allocate replica list
beginrepair failed.
repair > beginrepair blah
Could not allocate new repvol: Object not in conflict
beginrepair failed.
repair > 13:30:35 Local inconsistent object at /coda/usr/samir/blah,
please check!

If I do an 'ls -l blah' now, I get:

lrw-r--r--    1 root     nfsnobod       27 Apr 15 13:35 global ->
@7f000000.000018f2.000007ef
-rw-rw-r--    1 samir    nfsnobod       14 Apr 15 12:19 local


Also, at this point, it seems that I can make changes to directories
under /coda w/o even having authentication tokens (none of these
changes propagate back to the server though).  Pretty much, even
though the client thinks it's connected to the server.  If I do a 'cfs
listvol' on the directory, I get:

  Status of volume 0x7f000000 (2130706432) named "MLB_TEST"
  Volume type is ReadWrite
  Connection State is WriteDisconnected
  Minimum quota is 0, maximum quota is unlimited
  Current blocks used are 102772
  The partition has 3460228 blocks available out of 8041036
  Write-back is disabled
  *** There are pending conflicts in this volume ***
  There are 2 CML entries pending for reintegration

but I can't ever get the conflicts resolved.  The only way to get
things back to "normal" is to shut Coda down, and re-run venus-setup.
Occasionally, I can't even cleanly shutdown Coda (get timeout error's
trying to access /coda partition), in which case I just reboot the
client.

This is a fairly vanilla setup... I think.  It's got the latest
version of the Coda client and ver 5.3.19 of the server installed.
All the other utilities on the client side are up-to-date.  RPC, LWP,
etc. on the clients is all up-to-date, but these might be one or two
versions behind on the server.  The clients are running kernel ver
2.4.18, and the server has 2.4.19.

I have a feeling I'm missing something really simple, as this seems
like basic functionality.

Any help is more than welcome!

Thanks,

Samir
Received on 2003-04-15 15:55:26