On Wed, Feb 22, 2006 at 10:07:53AM -0500, Greg Troxel wrote:
> My server rebooted ungracefully (due to the xen dom0 below it
> rebooting), and now codasrv won't start up.  Srv{Log,Err} follow.
> Find of /usr (where /vice and /vicepa are) -inum 1562 and 1563 both
> turn up empty.

The inodes numbers it is complaining about are most likely not the
on-disk inode numbers of the container files, but are mapped to the
names depending on the fanout settings of the ftreedb (i.e. 255 = 0/0/f/f)

The log messages are probably still remnants from the time Coda used a
dedicated partition to store container files instead of a filesystem
tree and directly accessed container files with some userspace
implementation of iget/vget.

I think this is why there is a 'inoder' tool on the servers,

    # inoder /vice/db/vicetab /vicepa header 50
    Partition /vicepa: inodes in use: 5466, total: 16777216.

    Date: Wed 02/22/2006

    14:57:24 Partition /vicepa: 19593852K available (minfree=5%),
    19429384K free.
    Header for inode 50
    lnk   1
    vol   1000001
    vnode 140
    uniq  374
    vers  1
    magic 47114711

With this you can increment or decrement the linkcount of an object, it
doesn't look like it actually tells us what the path to the file in
question is.

What I think happened was that a file was in the process of being
added/updated while the server went down. The container file was
created, but the server crashed before the RVM transaction was
committed.

Then during recovery the incomplete RVM transaction was aborted, and
during salvage the server noticed there was a file that didn't have a
corresponding on-disk container file. It tries to recreate the container
file, which conflicts with the one that already exists.

I'm not sure why it complains about bitmap 1562 and inode 1563, maybe
bitmap bits are counted from 0, container file numbers counted starting
from 1.

If you know the ftreedb parameters (width,depth) it is possible to map
from the inode to the actual location.

lets say width is 256, and depth is 3, then we have 3 directory levels
deep, and 256 entries per directory.

So we take
    1563 % 256 = 27 = 0x1b  (depth 3)
    1563 / 256 = 6

    6 % 256    = 6  = 0x06  (depth 2)
    6 / 256    = 0

    0 % 256    = 0  = 0x00  (depth 1)

So I would expect this file to be located at, /vicepa/0/6/1b

If the server is trying to create an empty file container removing the
container file should fix the problem. If the fso happens to be a
directory it might crash later on because the newly created object
doesn't have '.' and '..' entries and such.

Jan