Date: Tue, 4 Apr 1995 23:31:17 +1596657 (MET DST) From: Wilko Bulte <wilko@yedi.iaf.nl> To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Cc: peter@bonkers.taronga.com, terry@cs.weber.edu, PVinci@ix.netcom.com, hackers@FreeBSD.org Subject: Re: large filesystems/multiple disks [RAID] Message-ID: <199504042131.XAA02370@yedi.iaf.nl> In-Reply-To: <199504041720.KAA07847@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Apr 4, 95 10:20:52 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > thus cutting effective bandwidth by 20%. It is actually worse than > > > this in that all writes must write to at least 2 drives no matter how > > > small they are. The removes some of the benifits of stripping. > > > > And that is why some RAID systems use (battery backed up please ;-) RAM > > caches. This works quite nicely. > > And you find these caches will fill up and some point in a sustained > write test and you end up right back at the 20% performance loss I > was talking about. Sure, that is the nature of caches..;-) But for sustained writes you'd probably go for RAID3 (parallel writes on multiple disks) iso RAID5 where you hope that the I/O more or less evenly distributes on each chunk/disk. The EXOR for the RAID5 can also be done in hardware. > Pure stripping of drives always outperforms RAID, you always pay some > price for reliability, and it is usually performance or $$$. Throw some money at it and mirror the stripe sets. Do this controller based in the disksubsystem and your host doesnot have the overhead (which should not be too much when properly implemented on the right hardware even when host based) Wilko _ __________________________________________________________________________ | / o / / _ Wilko Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Private FreeBSD site - Arnhem - The Netherlands --------------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504042131.XAA02370>