From owner-freebsd-current Thu Mar 23 15:28:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id 1BC4737C52C for ; Thu, 23 Mar 2000 15:28:10 -0800 (PST) (envelope-from grog@mojave.worldwide.lemis.com) Received: from mojave.worldwide.lemis.com ([216.88.157.130]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id JAA02329; Fri, 24 Mar 2000 09:57:45 +1030 (CST) (envelope-from grog@mojave.worldwide.lemis.com) Received: (from grog@localhost) by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09537; Thu, 23 Mar 2000 15:27:18 -0800 (PST) (envelope-from grog) Date: Thu, 23 Mar 2000 15:27:18 -0800 From: Greg Lehey To: Dan Nelson Cc: Poul-Henning Kamp , Alfred Perlstein , Matthew Dillon , current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <20000323152718.C9318@mojave.worldwide.lemis.com> Reply-To: Greg Lehey References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320152330.A48212@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000320152330.A48212@dan.emsphone.com>; from dnelson@emsphone.com on Mon, Mar 20, 2000 at 03:23:31PM -0600 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 20 March 2000 at 15:23:31 -0600, Dan Nelson wrote: > In the last episode (Mar 20), Poul-Henning Kamp said: >> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes: >>> * Poul-Henning Kamp [000320 11:45] wrote: >>>> >>>> Before we redesign the clustering, I would like to know if we >>>> actually have any recent benchmarks which prove that clustering is >>>> overall beneficial ? >>> >>> Yes it is really benificial. >> >> I would like to see some numbers if you have them. > > For hardware RAID arrays that support it, if you can get the system to > issue writes that are larger than the entire RAID-5 stripe size, your > immensely slow "read parity/recalc parity/write parity/write data" > operations turn into "recalc parity for entire stripe/write entire > stripe". RAID-5 magically achieves RAID-0 write speeds! Given 32k > granularity, and 8 disks per RAID group, you'll need a write > size of 32*7 = 224k. Given 64K granularity and 27 disks, that's 1.6MB. > > I have seen the jump in write throughput as I tuned an Oracle > database's parameters on both Solaris and DEC Unix boxes. Get Oracle > to write blocks larger than a RAID-5 stripe, and it flies. Agreed. This is on the Vinum wishlist, but it comes at the expense of reliability (how long do you wait to cluster? What happens if the system fails in between?). In addition, for Vinum it needs to be done before entering the hardware driver. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message