From owner-freebsd-hackers Tue Nov 10 23:52:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17069 for freebsd-hackers-outgoing; Tue, 10 Nov 1998 23:52:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from news2.du.gtn.com (news2.du.gtn.com [194.77.9.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17056 for ; Tue, 10 Nov 1998 23:52:07 -0800 (PST) (envelope-from ticso@cicely5.cicely.de) Received: from cicely.cicely.de (cicely.de [194.231.9.142]) by news2.du.gtn.com (8.8.6/8.8.6) with ESMTP id IAA07919; Wed, 11 Nov 1998 08:51:45 +0100 (MET) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) by cicely.cicely.de (8.8.8/8.8.8) with ESMTP id IAA18365; Wed, 11 Nov 1998 08:52:01 +0100 (CET) Received: (from ticso@localhost) by cicely5.cicely.de (8.9.0/8.9.0) id IAA27224; Wed, 11 Nov 1998 08:51:52 +0100 (CET) Message-ID: <19981111085152.55040@cicely.de> Date: Wed, 11 Nov 1998 08:51:52 +0100 From: Bernd Walter To: Greg Lehey , 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19981111134546.D20374@freebie.lemis.com>; from Greg Lehey on Wed, Nov 11, 1998 at 01:45:46PM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. I agree - In general bigger stripes are better for Multiitasking Systems. > > >>> There was an interesting symptom observed in striped mode, where the > >>> disks seemed to have a binarily-weighted access pattern. > >> > >> Can you describe that in more detail? Maybe I should consider > >> relating stripe size to cylinder group size. > > > > I always saw the same and I'm shure that the cylinder groups are > > mostly placed on one disk each. > > I think you mean the superblocks. It depends on the cylinder group > size. I haven't thought about this yet, but I may well do so. You are right - I mean super-blocks and inode areas of the c-groups. > [...] > > 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. > > 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. You don't have to worry about loading an lkm or fsck, ... Maybe I missed anything - but the last time I wasn't able to find any point for vinum in any rc file. > > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key -- B.Walter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message