Date: Thu, 19 Sep 1996 14:53:04 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Cc: jgreco@brasil.moneng.mei.com, henrich@crh.cl.msu.edu, freebsd-isp@FreeBSD.ORG Subject: Re: News server... Message-ID: <199609191953.OAA11437@brasil.moneng.mei.com> In-Reply-To: <199609191800.LAA07104@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Sep 19, 96 11:00:22 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Perhaps some one should dig up the 1987 UCB paper by Patterson, Gibson > and Katz titled ``A Case for Redundant Arrays of Inexpensive Disks (RAID)'', > I am sure they covered something about configuring the stripe size > very large for high TPS rates, and very small for high bandwidth. Ah.. > I did find the UCB report number: UCB/CSD 87/391. FOUND it! THANKS Rod, you are always a wealth of valuable knowledge... http://cs-tr.cs.berkeley.edu/Dienst/UI/2.0/Page/ncstrl.ucb/csd-87-391/10?npages=26 "A better measure for database systems is the number of _individual_ reads or writes per second. [...] Ideally during small transfers each disk in a group can act independently, either reading or writing independent information." http://cs-tr.cs.berkeley.edu/Dienst/UI/2.0/Page/ncstrl.ucb/csd-87-391/11?npages=26 (nice picture) However, the paper is entirely too preoccupied with the "R" in RAID, and does not give a lot of information about stripe sizes, etc. http://cs-tr.cs.berkeley.edu/Dienst/UI/2.0/Page/ncstrl.ucb/csd-87-391/22?npages=26 is probably the most "useful" if you simply look at the grey bars in the data plot, but is still comparing mirrored or redundant disks... > I did find this in some other sales lit I have: > ``In I/O intensive environments, performance is optimized by striping > the drives in the array with stripes large enough so that each record > potentially falls entierely within on stripe.'' > ... > > Unfortunately, small stripes rule out multiple overlapped I/O operations, > since each I/O will typically involve all drives.'' Big nod. > I think in the usenet news engine case we can safely call the update > record a ``cylinder group'', since any file add/remove/read is almost > always going to fall within 1 cylinder group (except when UFS's optimizations > fail.) Well, that was MY logic...! :-) And I know it is not "perfect", but it is the best tradeoff I could envision. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609191953.OAA11437>