From owner-freebsd-hackers Thu Nov 12 18:34:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05976 for freebsd-hackers-outgoing; Thu, 12 Nov 1998 18:34:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05951 for ; Thu, 12 Nov 1998 18:34:43 -0800 (PST) (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 NAA26937; Fri, 13 Nov 1998 13:04:13 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id NAA01719; Fri, 13 Nov 1998 13:03:50 +1030 (CST) Message-ID: <19981113130349.N781@freebie.lemis.com> Date: Fri, 13 Nov 1998 13:03:49 +1030 From: Greg Lehey To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone References: <19981113125134.M781@freebie.lemis.com> <199811130229.SAA02465@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199811130229.SAA02465@dingo.cdrom.com>; from Mike Smith on Thu, Nov 12, 1998 at 06:29:06PM -0800 WWW-Home-Page: http://www.lemis.com/~grog 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 Thursday, 12 November 1998 at 18:29:06 -0800, Mike Smith wrote: >>>> The four-layer concepts used by Veritas and Vinum have always been >>>> difficult to understand. I'm trying to work out how to explain them >>>> better, but taking the Microsoft-style "don't worry, little boy, I'll >>>> do it all for you" approach is IMO not the right way. >>> >>> I think it's a mistake to conceal all the workings, but it's also a >>> mistake to assume that for the "common case", you need to thrust all of >>> it into the novice's face. >>> >>> The "common case" for RAID applications seems to be: "I have these >>> disk units, and I want to make them into a RAID volume". So the >>> required functionality is: >>> >>> 1) Input the disks to participate in the volume. >> >> drive a device /dev/da0h >> drive b device /dev/da1h >> drive c device /dev/da2h >> drive d device /dev/da3h >> drive e device /dev/da4h >> >>> 2) Input the RAID model to be used. >> >> plex org raid5 256k >> >>> Step 2 should check the sizes of the disks selected in step 1, and make >>> it clear that you can only get striped or RAID 5 volumes if the disks >>> are all the same size. >> >> You haven't said how big you want it yet. > > Yes I have. I've said I want to use all of these disks. Use them all, > dammit. Ah. OK. >>> If they're within 10% or so of each other, it should probably ignore >>> the excess on the larger drives. >> >> Why? That would be a waste. Just say: >> >> sd drive a length 5g >> sd drive b length 5g >> sd drive c length 5g >> sd drive d length 5g >> sd drive e length 5g > > If you have two drives 4.1GB and two that are 4.3GB, and you want to > stripe them, you have to use a base size of 4.1GB and throw away 400MB. > Either that, or you subdivide the disks into multiple partitions > looking for the largest common submultiple. Yuck. That's exactly what we do, except that we don't throw away the rest: it remains available for other plexes. 400 MB could come in handy somewhere. You'd write: sd drive a length 4100m sd drive b length 4100m sd drive c length 4100m sd drive d length 4100m What's the problem? 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