On Wed, Jul 06, 2005 at 03:40:22PM -0600, Patrick Walsh wrote:
> 12:53:18 readline-4.2-2.i386.rpm (5086c448.7f000003.1018.4de)
> inconsistent!
> 12:53:18 fatal error -- fsobj::dir_Create: (dir225,
> 5086c448.7f000003.fffffffc.802a7) Create failed!
> 12:53:18 RecovTerminate: dirty shutdown (1 uncommitted transactions)
> Assertion failed: 0, file
> "/home/pwalsh/working/coda/BUILD/coda-6.0.11/coda-src/venus/fso_dir.cc",
> line 95
> Sleeping forever.  You may use gdb to attach to process 9980.
> 
> 	venus.log really doesn't show anything interesting (to my eye anyway).

There doesn't really seem to be a real problem with the rpm, besides the
fact that it is inconsistent and needs to be repaired. The actual
problem seems to be that we're unable to add a name to a directory.

> 	Question 2: what happened?  

I would guess there is a directory that has exceeded the 256KB limit.

Because of the vnode number (fffffffc), it is an automatically created
fake file identifier, which is probably created as a result of the
inconsistency. Maybe it is trying to add a dangling symlink object in
place of the parent directory where that file is located. So this would
indicate that it is a local-global (reintegration) conflict.

So your client was creating files in connected mode, got disconnected,
but the operation completed at the servers. Then when it tried to
reintegrate the failed store operation it hit a conflict on the store
identifier. This marked the object as in conflict, but repair somehow
decided that (I guess) the parent directory had to be marked as the
conflict. For local-global repair this means unlinking the old name, and
replacing it with a new name pointing at a local fake object (dangling
symlink or expanded directory). However this happens in a single
transaction, so we don't actually replace the fid in the old entry, but
unhash the old name/fid entry, and allocate a new entry with the new
name/fid pair.

This pushed the parent directory over the 256KB limit and dir_Create
failed, triggering an assertion.

> 	Question 1: is there any way to get rid of this file of death so we can
> salvage this installation?

Reinitializing the client would get rid of the CML so it won't try to
reintegrate and get rid of the 'local-global' part of the conflict.
There might still be a server-server conflict but those are handled
differently and do not replace entries in the parent directory, so it
shouldn't push the directory past the 256KB limit.

Jan