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