Date: Tue, 11 Dec 2001 17:08:04 +0100 From: Bernd Walter <ticso@cicely8.cicely.de> To: Wilko Bulte <wkb@freebie.xs4all.nl> Cc: Greg Lehey <grog@FreeBSD.ORG>, Matthew Dillon <dillon@apollo.backplane.com>, Mike Smith <msmith@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, freebsd-current@FreeBSD.ORG Subject: Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c) Message-ID: <20011211170803.C15004@cicely8.cicely.de> In-Reply-To: <20011211153437.A69755@freebie.xs4all.nl> References: <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211153437.A69755@freebie.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 11, 2001 at 03:34:37PM +0100, Wilko Bulte wrote:
> On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
> > I think this is what Mike was referring to when talking about parity
> > calculation. In any case, going across a stripe boundary is not a
> > good idea, though of course it can't be avoided. That's one of the
> > arguments for large stripes.
>
> In a former life I was involved with a HB striping product for SysVr2
> that had a slightly modified filesystem that 'knew' when it was
> working on a striped disk. And as it know, it avoided posting I/O s
> that crossed stripes.
Here some real world statistics with UFS softupdates:
Plex d1.p0: Size: 8736473088 bytes (8331 MB)
Subdisks: 3
State: up
Organization: striped Stripe size: 256 kB
Part of volume d1
Reads: 83546
Bytes read: 258429952 (246 MB)
Average read: 3093 bytes
Writes: 100109
Bytes written: 818750464 (780 MB)
Average write: 8178 bytes
Multiblock: 279 (0%)
Multistripe: 82 (0%)
Subdisk 0: d1.p0.s0
state: up size 2912157696 (2777 MB)
Subdisk 1: d1.p0.s1
state: up size 2912157696 (2777 MB)
Subdisk 2: d1.p0.s2
state: up size 2912157696 (2777 MB)
You can easily see that the number of Multistripe transactions are
unnoticeable low.
Here another case with 64k stripe size:
Plex d7.p0: Size: 36419796992 bytes (34732 MB)
Subdisks: 2
State: up
Organization: striped Stripe size: 64 kB
Part of volume d7
Reads: 934001
Bytes read: 3718752768 (3546 MB)
Average read: 3981 bytes
Writes: 220293
Bytes written: 3702993920 (3531 MB)
Average write: 16809 bytes
Multiblock: 50037 (4%)
Multistripe: 25047 (2%)
Subdisk 0: d7.p0.s0
state: up size 18209898496 (17366 MB)
Subdisk 1: d7.p0.s1
state: up size 18209898496 (17366 MB)
You can see that even we have an absolute extrem situation the number
of multistripe transactions is still very low.
But a value of 384k would be a much better value for other reasons.
You may want to compare the multistripe number with the multiblock number
and yes it doesn't look that good anymore, but you also see that the
change from 64k to 256k get much better results, while the average
transaction size is 5865 bytes for the first case and 6429 bytes for
the second - not that different.
Most of my plexes are concat anyway.
--
B.Walter COSMO-Project http://www.cosmo-project.de
ticso@cicely.de Usergroup info@cosmo-project.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011211170803.C15004>