Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Nov 2004 09:53:20 +1030
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        Lukas Ertl <le@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: Gvinum RAID5 performance
Message-ID:  <20041106232320.GI24507@wantadilla.lemis.com>
In-Reply-To: <20041031235355.R1732@korben.prv.univie.ac.at>
References:  <002401c4bf9c$c4fee8e0$0201000a@riker> <20041031235355.R1732@korben.prv.univie.ac.at>

next in thread | previous in thread | raw e-mail | index | archive | help

--Op27XXJsWz80g3oF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sunday, 31 October 2004 at 23:56:17 +0100, Lukas Ertl wrote:
> On Mon, 1 Nov 2004 freebsd@newmillennium.net.au wrote:
>
>> Now, running a dd from a plex gives me less performance than running a
>> dd from one of the subdisks, even though the array is not running in
>> degraded mode.
>
> I'd consider this normal behaviour, since you have to go through the
> offset calculation.

The offset calculations should run at several orders of magnitude
faster than the disk transfers.  If reading a plex is slower than
reading the subdisk, I can see two reasons:

1.  Too small a stripe size.  If you (our anonymous user, who was
    using a single dd process) have to perform multiple transfers for
    a single request, the results will be slower.
2.  There may be some overhead in GEOM that slows things down.  If
    this is the case, something should be done about it.

I'm pretty sure that the old Vinum would not show this kind of
behaviour if (1) doesn't apply.

Greg
--
See complete headers for address and phone numbers.

--Op27XXJsWz80g3oF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFBjVzoIubykFB6QiMRAgs8AJ9inj+zVJ58hfQxA1H7fTNmgCbsewCfTsx8
VJr1anV4+I4OjffedirmyQY=
=HNXK
-----END PGP SIGNATURE-----

--Op27XXJsWz80g3oF--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041106232320.GI24507>