(Illustration by Gaich Muramatsu)
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. JanReceived on 2001-07-05 09:25:33