On Tue, Jul 03, 2001 at 12:37:26PM +0200, Steffen Neumann wrote:
> We now have the problem that the server
> seems to be extremely unstable, 
> resulting in a complete halt (yuk) of the system.
> 
> In the SrvLog there are a number of suspicious 
> entries, of which I included only a few at the end.
> I'd like to know whether and how I can solve them.
> 
> Yours,
> Steffen
> 
> 12:17:54 DCC: Warning - uniquifier is too low for volume (0x100004c)

Normal, the current highest used uniquifier is only occasionally synced
to RVM, during salvage we simply bump it up if we see a higher one. Even
if the uniquifier is not bumped, the chance of getting FID conflicts
(same volume/vnode/uniquifier) remains very low.

> 12:17:54 VICheck: Found old inode 7958 for vnode number 6

I see these a lot as well. Haven't figured out why these old inodes
aren't being cleaned up.

> 12:17:54 SFS:No Inode summary for volume 0x1000008; skipping full salvage

Empty volume, not a problem.

> 12:18:39 ValidateVolumes: 0x7f00002d failed!
> 12:18:50 ViceValidateAttrs: (100001b.a3.fe6) failed ()!

A client has a different version of some files in it's cache, maybe the
server missed an update on a replicated volume. The next time the
related files are accessed the difference is detected and quietly
resolved in the background.

The reason for 2.4.x instabilities could be the absolute horrible state
of the kernels VM layers. Coda servers use a lot of VM, and there are
several serious problems with the recent 'stable' kernels as far as
memory management is concerned. 2.4.5 and the upcoming 2.4.6 kernels
should be getting somewhat better in that area.

Once surprising difference is that with new kernels you really need at
least twice as much swap as memory, as swapspace isn't reclaimable until
the swapped out process dies.

Jan