From owner-freebsd-hackers Thu Oct 22 15:54:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA16582 for freebsd-hackers-outgoing; Thu, 22 Oct 1998 15:54:24 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from plaidsocks.com (c35486-a.frmt1.sfba.home.com [24.1.70.247]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA16565 for ; Thu, 22 Oct 1998 15:54:12 -0700 (PDT) (envelope-from stefan@csudsu.com) Received: from localhost (stefan@localhost) by plaidsocks.com (8.8.8/1.3.2) with SMTP id PAA15849; Thu, 22 Oct 1998 15:52:39 -0700 (PDT) (envelope-from stefan@csudsu.com) Date: Thu, 22 Oct 1998 15:52:38 -0700 (PDT) From: Stefan Molnar X-Sender: stefan@c35486-a.frmt1.sfba.home.com To: Terrance Young cc: Hallam Oaks , "freebsd-chat@FreeBSD.ORG" Subject: Re: Multi-terabyte disk farm In-Reply-To: <362F8D9C.ACDA3BF0@hmsa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Goto http://now.cs.berkeley.edu/Td/td.html to see what Berkeley did on something like this. They user FreeBSD 3.0 current http://now.cs.berkeley.edu/Td/arch.html On Thu, 22 Oct 1998, Terrance Young wrote: > Hi... > > Hallam Oaks wrote: > > > G'Day; > > > > I've a few things I'd like, If I may, to get opinions on. > > ok... my opinions and semi-thoughts :-) below... > > <...Snip.. Ouch that was my fingers!..> > > > With current hard drive prices, I estimate we can put together a one > > terabyte disk farm for about US$60k (cost of media only), spread across > > several machines using hot swappable drive bays and dual SCSI buses per > > machine. We don't intend to use RAID unless there's strong advantages to > > it (I don't know a whole lot about it). We don't need striping or > > replication. > > I think a Raid would serve you better in up time and reliabilty. > RAID is a bit slower but has good error correction and fault tolerance. > > > > > One advantage of doing it via a distributed farm (I theorise) is that if > > one drive fries or one machine self-destructs, at least the rest of the > > system will still be working. A fried drive can be restored from one of > > the 25gb AIT backup tapes made of all the dubs. > > Humm.. Depends on how you do it I suppose... > but if not raid on the data drives then at least mirroring on the OS drives.. > and keep the data drives separate... (where's my coffee...) > > <...Snip! humm I seem to be losing fingers...> > > > > > Needless to say I'm going to put my preferred solution as FreeBSD-based. > > Some of the criteria that I can't yet answer and would like feedback on > > are these - > > My Preferred choice ;-) > > > > > o is FreeBSD able to be made to recognise a new SCSI drive that wasn't > > present on boot ? i.e. a new drive is plugged into the hot bays. can > > it be recognised, formatted, and mounted by manual intervention ? > > Sure! no prob... if you had a Hot Swap chassis... > > > o ditto if a drive fries. can it be taken out without the kernel getting > > too upset ? > > Yup! as long as its in a hot swap chassis and not the > OS mirrored drive hehe.. then I think you might have slight problems but it > will come back up on the one good drive (how bad I'm not sure, hasn't happened > to me yet *knocks on wood*).. > > > o is it feasable to automatically umount and spin down drives that > > haven't been accessed for a day or so ? typically, the older data > > (> 6 months) will be rarely, if ever, accessed before its two-year > > span expires and it's erased. > > Humm...yup, you can spin it down when not accessing it when you use it again > it might give you a timeout error which I think is sort of normal at least > until the drive spins back up... > > > o would the boot time of a system be dramatically prolonged by it having > > 500 or so gigabytes of SCSI drives hanging off its backside ? (I'm > > referring to a normal boot, with the drives having been properly > > unmounted. I don't even want to THINK about waiting on an fsck of 500 > > gigs of unclean disk ;). OTOH the size of the files is quite large, so > > it'd be feasable to use huge nodes. > > Yuck, Wash it :-) don't want to touch unclean disks hehe... > But as to booting up a bit longer due to the amout of drives.. > shouldn't be too unbearable... > > > I've no particular objection to a reboot if need be to add/remove a > > drive, but if it took more than, say, 10 minutes, it'd be an issue I'd > > have to tackle with management. > > Hehe... How fast can you change Disks? I think it would be at least a bit > longer to powerdown, change drive and power up with 500 gigs...(go Hot Swap! > less headaches and you don't need Pit Crew speed hehe...) > > > o we're thinking of using Seagate Elite 47gb drives. These are 5400 RPM > > units (speed isn't an issue to us). Does anyone have any opinions > > about these (good/bad/indifferent) or of previous members of that > > drive family ? > > Personally I get wary of Very Large Drives still... (hope the room is real > cool) > I'm still not too sure of the reliability yet...we'll see...the largest we > have are 14 gig > drives seems to be holding up so far... but 47 gig humm... does anyone you > know been using those for a while (at least as long as they been out)? > > <...Snip... whew! missed my fingers that time!...> > > > I guess my main interest, despite the above questions, is really to hear > > if others think this is a realistic goal to be aiming for, and if others- > > who-have-gone-before-me have struck major problems doing the same (or a > > similar) thing. > > I think its feasable If you aren't too worried about your data if you aren't > going the raid route but at least go with hot swappable saves some headache... > Spinning down the drives I heard some various problems early on in '97 about > that but not too much lately... > > Terrance > > Damn what a little research can do.. :-) > My few opinions... and fingers... :-) not to be taken with water or used when > operating a WinDOZE machine :-) (Hey why'd they give me that NT workstation > for...must be to practice rebooting...) > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message