(Illustration by Gaich Muramatsu)
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. JanReceived on 2006-02-22 15:11:33