Sigh, third time I'm typing this reply, I keep losing my dialup
connection this morning..

On Thu, Oct 17, 2002 at 03:34:15PM +0200, Steffen Neumann wrote:
> The old filesystem had errors on a number of files:
> 
> 	 ./1/5b/18: Input/output error
> 	 ./1/5b/19: Input/output error
> 	[...]
> 	 ./1/5b/37: Input/output error
> 
> How do we find those files we have to get from the 96 hour old backup ? 
> We'd like to keep those to a minimum, of course...

The FREEDB file contains the mapping of container files to fids. There
is a program called 'inoder' that can be used to read it, and it should
be installed in /usr/sbin on the servers.

You should be able to do 'inoder /vice/db/vicetab /vicepa header <inum>

Where inum is derived from the pathname as follows,

    check in the vicetab file what the width and depth are, actually it
    is pretty clear that depth is 3, and width is probably either 128 or 256.

    Let's take ./1/5b/18 as an example,

    inum = either, 0x1 * 128 * 128 + 0x5b * 128 + 0x18 = 28056
	   or,     0x1 * 256 * 256 + 0x5b * 256 + 0x18 = 88856

>         13:47:05 SFS:No Inode summary for volume 0x1000009; skipping full salvage
>         13:47:05 SalvageFileSys: Therefore only resetting inUse flag

This should be normal for any volume without files, we have a bunch of
these when servers are started.

>         13:47:05 Entering DCC(0x100000a)
>         13:47:05 DCC: Salvaging Logs for volume 0x100000a
>         
> 	13:47:05 done:  823 files/dirs, 108199 blocks
> ----
> 	13:48:03 SalvageFileSys:  unclaimed volume header file or no Inodes in volume 10
> 	13:48:03 SalvageFileSys: Therefore only resetting inUse flag

Considering that there are 823 files, I'm assuming that it has an
unclaimed volume header file. Not sure what that is, but the server came
up, so it is probably ok. Servers tend to lock up solid if they find
discrepancies they don't like.

> gave us 
> 
> 	14:15:10 TryToCover: bogus link length
> 
> What does that mean ?

A dangling symlink (i.e. mountlink) that has a length that is smaller
than the minimal number of characters needed to make it a valid
mountpoint. i.e. a normal name is "#volume.", so it should have at
least 2 characters, this one probably has a length of 0 or 1. Maybe one
of the lost files was storing the 'contents' of the symlink?

Jan