From owner-freebsd-hackers Thu Aug 5 18:24:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id A2FB914BD5 for ; Thu, 5 Aug 1999 18:24:36 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA13960; Fri, 6 Aug 1999 10:53:57 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA79404; Fri, 6 Aug 1999 10:53:55 +0930 (CST) Date: Fri, 6 Aug 1999 10:53:54 +0930 From: Greg Lehey To: Bernd Walter Cc: Stephen Hocking-Senior Programmer PGS Tensor Perth , hackers@FreeBSD.ORG Subject: Re: Adding disks -the pain. Also vinum Message-ID: <19990806105354.T5126@freebie.lemis.com> References: <19990803133554.S62948@freebie.lemis.com> <199908030416.MAA16945@ariadne.tensor.pgs.com> <19990803081216.B23148@cicely8.cicely.de> <19990803155945.W62948@freebie.lemis.com> <19990803232044.A25368@cicely8.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.4i In-Reply-To: <19990803232044.A25368@cicely8.cicely.de>; from Bernd Walter on Tue, Aug 03, 1999 at 11:20:45PM +0200 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 3 August 1999 at 23:20:45 +0200, Bernd Walter wrote: > On Tue, Aug 03, 1999 at 03:59:46PM +0930, Greg Lehey wrote: >> On Tuesday, 3 August 1999 at 8:12:17 +0200, Bernd Walter wrote: >> >>> For UFS/FFS there is nothing worth seting the stripesize to low. >>> It is generally slower to acces 32k on different HDDs than to acces 64k on >>> one HDD. >> >> It is always slower where the positioning time is greater than the >> transfer time for 32 kB. On modern disks, 32 kB transfer in about 300 >> µs. The average rotational latency of a disk running at 10,800 rpm is >> 2.8 ms, and even with spindle synchronization there's no way to avoid >> rotational latency under these circumstances. > > It shouldn't be the latency, because with spindlesync they are the same > on both disks if the transfer is requested exactly the same time what > is of course idealized.. Spindle sync ensures that the same sectors on different disks are under the heads at the same time. When you perform a stripe transfer, you're not accessing the same sectors, you're accessing different sectors. There's no way to avoid rotational latency under these circumstances. > The point is that you have more then a single transfer. With small > transfers spindle sync is able to winback some of the performance > you have lost with a to small stripe size. No, this isn't correct, unless you're running 512 byte stripes. In this case, a single-stripe transfer of, say, 8 kB with the disks above would take about 7 ms total latency (same as with a single disk), but the transfer would take less time--5 µs instead of 80 µs. You'd need 16 disks, and you'd tie them all up for 7 ms. And this doesn't consider the times of SCSI command setup and such. Basically, this is not the way to go if you have multiple clients for your storage. Look at http://www.lemis.com/vinum/problems.html and http://www.lemis.com/vinum/Performance-issues.html and for more details. >>> Spindle Sycronisation won't bring you that much on modern HDDs - I tried >>> it using 5 Seagate Elite 2.9G (5,25" Full-Height). >> >> It should be useful for RAID-3 and streaming video. > > I case of large transfers it will make sense - but FFS is unable to set > up big enough requests. No, this is a case where you're only using one client, so my argumentation above doesn't apply (since you're reading sequentially, so latency is no longer an issue). Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message