From owner-freebsd-stable Tue Sep 19 4: 4:19 2000 Delivered-To: freebsd-stable@freebsd.org Received: from morpheus.skynet.be (morpheus.skynet.be [195.238.2.39]) by hub.freebsd.org (Postfix) with ESMTP id 4F43C37B424; Tue, 19 Sep 2000 04:04:13 -0700 (PDT) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by morpheus.skynet.be (Postfix) with ESMTP id C096FDF17; Tue, 19 Sep 2000 13:04:08 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: <200009190926.UAA03568@juju.bsn> References: <200009190926.UAA03568@juju.bsn> Date: Tue, 19 Sep 2000 12:41:42 +0200 To: atrn@zeta.org.au, stable@FreeBSD.ORG From: Brad Knowles Subject: Re: MFC of ahc driver updates (long-ish) Cc: "Brandon D. Valentine" , gibbs@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:26 PM +1100 2000/9/19, Andy Newman wrote: > Count me in for testing then. I currently have a very unstable system > with a 29160. I'm not exactly sure if its the 29160 or vinum that is > causing the problems. There's a new controller coming but while the > 29160 is there it may as well be used for some good. Hmm. It's really funny. I've got a Dell 2450 (512MB RAM, 600 Mhz Pentium III) w/ the on-board AIC-7899 controller (IIRC, it is 39160 equivalent), and five IBM DMVS18M 18GB 10kRPM UltraSCSI disks, running 4.1-STABLE from around Wed Aug 9 13:07:29 CEST 2000. One of the 18GB disks is the system disk, the other four are tied together with vinum and I have enabled softupdates. However, I am not using RAID-5, I am instead using mirroring+striping (it's for a mail queue, so I need the reliability of mirroring and the speed of striping). I have not yet been able to make this thing even hiccup, not matter what I've done to it (including lots of benchmarking, using it in its previous role as a Diablo 2.x news reader server, etc...). We wouldn't be using this machine for one of our primary inbound MXes for all mail handled on our systems if I wasn't 100% confident that this machine is very robust. The only significant differences that I can find between your system and mine are the Seagate drives (which I would expect to be at least as robust as the IBM drives I have, although I note you apparently ran into firmware problems with them), the VIA chipset, and the fact that you're running vinum in RAID-5 mode. > I've tried various file system configurations with some differences in > behavior. It appeared that soft updates or async mounts were quicker to > panic than a noasync mount (didn't try sync, didn't seem to be much fun > with GB's of I/O). Guess its the probably higher I/O ops > causing different patterns of buffer, control block usage, interrupt > activity, etc.., more chance of mess up with more complex pattern. I'm > also suspicious of the buffer corruption problem Greg Lehey still > mentions on his vinum know bugs page. Is that still around? Or is the > page stale? If you want to test your higher I/O operations theory, try throwing away your vinum RAID-5 configuration and rebuilding that as a pure striped device. Then try to beat the crap out of it. If that works, then try building it as a striped+mirrored device (because you obviously want that additional level of protection for your production systems), and then try to beat the crap out of it again. I'm following this thread with great interest, and would appreciate it very much if people would try to help keep me up-to-date on all the related issues. Thanks! -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message