Date: Fri, 28 Apr 1995 09:57:17 -0700 From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Subject: wcarchive.cdrom.com (also known as ftp.freebsd.org) back up. Message-ID: <199504281657.JAA14637@violet.berkeley.edu>
next in thread | raw e-mail | index | archive | help
Some of you may have noticed (well, perhaps ALL of you, judging by the amount of emailed complaints we've received :-) that wcarchive.cdrom.com was down all last week. We went to pop a couple of extra drives into it and were treated to a rather complete and unexpected controller failure instead. We subsequently had some rather significant hardware hurdles to jump over, not the least of which was 3 brand-new Quantum Grand Prix 4.3GB hard drives going south unexpectedly. Given that this is 4 GPs I've lost in 4 weeks (2 of which died in completely different environmental circumstances, so it's not just our machine room), I think it's safe to say that Quantum may be having some quality control problems with these drives! :-( I've switched back to the Seagate Barracuda drives and all seems happy again. The Seagates are even about $100 cheaper, so my traditional prejudice against Seagate may be weakening here. Anyway, that's all somewhat beside the point. The machine is back up and running with the following configuration, just FYI: o Intel Triton chipset MB with 128MB of RAM o SMC PCI DC21040 based ethernet board o 3 Adaptec 2940 PCI SCSI controllers o 15 3GB drives (soon to be 18, once I get replacements) The new Triton based MB gives about 30% better performance to the cache, so we decided that it was worth sacrificing the extra 64MB of RAM that our older ASUS Neptune chipset, dual-Pentium motherboard gave us (6 SIMM sockets instead of just 4). We also didn't have much choice as the ASUS (or Neptune chipset) appears to have some serious hardware bugs that prevent it from working with more than 2 PCI SCSI controllers and/or 2 DMA bus-mastering devices. I can say that we tried for over 3 days with every conceivable controller combination available (I now have 6 extra PCI & EISA scsi controllers lying around :-) and had absolutely no luck until we switched to the new Triton MB. Once EDO memory and the new pipelined-burst SRAM cache is available, we'll be giving that a spin as well since the MB supports it. Just further confirmation of the fact that you CAN make a serious server out of a PC, but you'd damned well better know *exactly* what you're doing! The road is littered with the corpses of those who have picked the wrong combination or had the simple misfortune to be trying just a _little too early_ in the game before the hardware actually worked. :-) We were very lucky in finding an early Triton that actually did the job and it could have easily gone the other way. The operating system is FreeBSD-current, as available from the very same machine :-) For the first time we're actually running the very same bits we're "pushing out the door" and this is a nice milestone for us. For those that are curious, we will also be taking this distribution, modulo whatever fixes we add in the next couple of days, and sending it out as "FreeBSD 2.0.5" - essentially an interim release between 2.0R and 2.1R to buy us a little time to do 2.1R the way we want to do it and give folks something substantially better than 2.0R to run in the meantime. Those who read the <hackers@FreeBSD.org> mailing list will have already seen my pre-announcement of 2.0.5. Suffice it to say that we wouldn't be running this on wcarchive (our "flagship" machine, as it were) if we didn't feel pretty good about it, so I'll have little or no reservations about recommending 2.0.5 to folks who can't wait for 2.1R (though 2.1R will, of course, be better! :). More on 2.0.5 will be posted here very soon. Now all this isn't quite to say "come and get it!" on wcarchive. Those who have already logged into it have found that the limit is set to an unusually low 175 (down from 450). This is because the machine is still here at Walnut Creek on our T1 and "under observation." Since our poor T1 completely swamps out after about 150 sessions, we've set the limit down to prevent a total meltdown (we want some bandwidth left over to read the Playboy web pages too, you know! :-). This will cease to be a problem once it's been tested for a few more days and we can ship it back down to its regular location on the Internet backbone. This is all just to let everyone know what's going on.. We're sorry for the length of the outtage but hope that there will be some positive effects of all this as well, namely better performance of the machine and quite a bit more disk space than we had before. Thank you all for your patience! Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504281657.JAA14637>