Date: Wed, 11 Nov 1998 08:51:52 +0100 From: Bernd Walter <ticso@cicely.de> To: Greg Lehey <grog@lemis.com>, Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: [Vinum] Stupid benchmark: newfsstone Message-ID: <19981111085152.55040@cicely.de> In-Reply-To: <19981111134546.D20374@freebie.lemis.com>; from Greg Lehey on Wed, Nov 11, 1998 at 01:45:46PM %2B1030 References: <199811100638.WAA00637@dingo.cdrom.com> <19981111103028.L18183@freebie.lemis.com> <19981111040654.07145@cicely.de> <19981111134546.D20374@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981111085152.55040>