From owner-freebsd-hackers Wed Nov 11 00:06:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18501 for freebsd-hackers-outgoing; Wed, 11 Nov 1998 00:06:36 -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 AAA18466 for ; Wed, 11 Nov 1998 00:06:29 -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 SAA21733; Wed, 11 Nov 1998 18:35:47 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id SAA21087; Wed, 11 Nov 1998 18:35:46 +1030 (CST) Message-ID: <19981111183546.D20849@freebie.lemis.com> Date: Wed, 11 Nov 1998 18:35:46 +1030 From: Greg Lehey To: Bernd Walter , Mike Smith , hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone References: <199811100638.WAA00637@dingo.cdrom.com> <19981111103028.L18183@freebie.lemis.com> <19981111040654.07145@cicely.de> <19981111134546.D20374@freebie.lemis.com> <19981111085152.55040@cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19981111085152.55040@cicely.de>; from Bernd Walter on Wed, Nov 11, 1998 at 08:51:52AM +0100 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 Wednesday, 11 November 1998 at 8:51:52 +0100, Bernd Walter wrote: > On Wed, Nov 11, 1998 at 01:45:46PM +1030, Greg Lehey wrote: >> On Wednesday, 11 November 1998 at 4:06:54 +0100, Bernd Walter wrote: >>> On Wed, Nov 11, 1998 at 10:30:28AM +1030, Greg Lehey wrote: >>>> On Monday, 9 November 1998 at 22:38:04 -0800, Mike Smith wrote: >>> [...] >>> One point is that is doesn't aggregate transactions to the lower drivers. >>> When using stripes of one sector it's doing no more than one sector >>> transactions to the HDDs so at least with the old scsi driver there's no >>> linear performance increase with it. That's the same with ccd. >> >> Correct, at least as far as Vinum goes. The rationale for this is >> that, with significant extra code, Vinum could aggregate transfers >> *from a single user request* in this manner. But any request that >> gets this far (in other words, runs for more than a complete stripe) >> is going to convert one user request into n disk requests. There's no >> good reason to do this, and the significant extra code would just chop >> off the tip of the iceberg. The solution is in the hands of the user: >> don't use small stripe sizes. I recommend a stripe of between 256 and >> 512 kB. > > That's good for random performance increase - but for linear access a smaler > stripe size is the only way to get the maximum performance of all > disks together. No, the kind of stripe size you're thinking about will almost always degrade performance. If you're accessing large quantities of data in a linear fashion, you'll be reading 60 kB at a time. If each of these reads requires accessing more than one disk, you'll kill performance. Try it: I have. >>> I never checked if it's possible to do a stripe on differend sized >>> disks as ccd can do. >> >> Do you mean 'different sized disks' or 'different sized subdisks'? >> Different sized disks are no problem, of course, but 'different sized >> subdisks' are. I don't think that ccd could do this either; it would >> leave a hole in the volume. > > I mean 'different sized subdisks'. > CCD has the interleave description table for doing such things. > It' described in sys/ccdvar.h . > Say you have 3 100M subdisks and 2 200M Subdisks then CCD make a stripe > on the first 500M with all 5 disks and on the last 200M with the remaining both. Ah, *that*'s why it has an interleave table. Score one for ccd. >>> And ccd is more integrated into the rest of the system but the other >>> things are working at least as good as with ccd. >> >> In which way is it better integrated? It's available in exactly the >> same way as ccd (unless, like you, you want RAID-5 :-) > > What I mean is - you edit /etc/ccd.conf and setup the partitions, ... > Finaly you place an entry in /etc/fstab. OK, with vinum you edit /etc/vinumconf and setup the partitions, then you place an entry in /etc/fstab. Not much difference. OK, /etc/rc.conf doesn't currently know about Vinum, and that's a thing I can look at. > You don't have to worry about loading an lkm or fsck, ... Well, you either load an LKM or build a kernel. And there's no difference between ccd and Vinum as regards the necessity for fsck. > Maybe I missed anything - but the last time I wasn't able to find any > point for vinum in any rc file. Yes, as I said, that's a valid point. I'll sort it out Real Soon Now. 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