Coda File System

Re: Venus reintegration error 198

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Sun, 5 Oct 2003 23:35:15 -0400
On Fri, Oct 03, 2003 at 01:45:46PM +0200, Florian Schaefer wrote:
> 13:10:08 Local inconsistent object at ???/anderes/config, please check!
> 13:10:08 Reintegrate: florian, 4/4 records, result = Unknown error 198

Ok, reintegration conflict, this should 'freeze' the volume and CML
until we repair.

> 13:10:15 fatal error -- cmlent::thread: can't find
> (50294108.7f000001.151.caa)

But about 7 seconds later we try to 'thread' the CML, but an object is
missing. I don't know whether this is due to a repair action (i.e.
repair preservelocal) or the after effect of a discardlocal repair
operation, but I don't think it can be a result of 'normal venus
operation' as we shouldn't try to reintegrate a volume with a conflict.

> [ I(22) : 0000 : 13:10:08 ] volent::IncReintegrate: fail code = 198
> 	ClientModifyLog: owner = 500, count = 4
> 	  current stats:    1	      0.2	 21.5	  3	    0.8
> 	cancelled stats:    0	      0.0	  0.0	  0	    0.0
> [...]
> 0x50311748 : fid = (50294108.7f000001.6f4.3bb), comp = posted, vol =

Ehh, it looks like you snipped the part in the log where it crashed. But
I guess that means there really wasn't anything interesting there.

If you still have the log, you could try to find whether it dumped the
contents of the object with fid (50294108.)7f000001.151.caa. It also
looks like this was just after a venus restart. Was there anything in
the console about discarding a dirty or local(ized) object? It might
have discarded the object during startup because it had a bad filesize
or some unusual bit set (owrite?). Or did venus crash while trying to
reintegrate it the first time? (shadow files are not yet persistent, but
recloned from the original during venus startup, but that fails when the
file was open for write when venus went down.

Jan
Received on 2003-10-05 23:36:19