From: Bill Davidsen <davidsen@tmr.com>
To: Daniel Nilsson <daniel.n.nilsson@home.se>
Cc: Markus.Lidel@shadowconnect.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Performance degradation when using partitions
Date: Tue, 22 Nov 2005 10:48:41 -0500 [thread overview]
Message-ID: <43833DD9.2060108@tmr.com> (raw)
In-Reply-To: <20051109182300.GA27452@oden.homeip.net>
Daniel Nilsson wrote:
> While setting up a software RAID-5 array I started looking into the
> performance aspect of using partioned drives versus the whole disks
> for a RAID-5 array. I have an Adaptec 2400a controller which through
> the I2O kernel driver gives me access to 4x 250GB disks (JBOD mode).
Did you get an answer on this? And does it happen if you use the drives
directly, /dev/hdN or /dev/sdN instead of using I2O? I didn't see an
obvious speed penalty in raw access of drives vs. partitions, but I
lacked the hardware to really match your setup, particularly the I2O use
vs. direct access to /dev/sd[ef].
>
> If I create the raid array on the disks directly, /dev/i2o/hd[abcd] I
> can tell from /proc/mdstat that the RAID-5 array is rebuilding at a
> rate of about 25MB/sec. If I instead first create one large primary
> partition on the drives and then create the raid array on those
> partitions /dev/i2o/hd[abcd]1 the array is rebuilding at roughly half
> the speed (14MB/sec).
>
> Not trusting this is a good performance measurement I went ahead and
> created a 10GB filesystem (ext3) on top of the resulting 700GB RAID-5
> array just to find that the speed of the resulting array was affected
> quite a bit by using partioned drives versus whole disks. Here are the
> results, note that the RAID-5 array was still rebuilding while
> performing these benchmarks.
>
> ------Sequential Output------ --Sequential Input- --Random-
> --Block-- -Rewrite- ---FS--- --Block-- --Seeks--
> K/sec %CP K/sec %CP K/sec %CP /sec %CP
> Whole disks: 44242 16 21290 7 Ext3 56547 12 290.9 0
>
> Partitioned: 28383 10 15496 5 Ext3 55089 12 288.9 0
>
>
> Next step was then to compare performance on just accesses to a single
> drive with a filesystem (ReiserFS or ext3) where the file system either
> occupied the whole disk or resided in a partition that covered the
> whole disk. Here are the results:
>
> ------Sequential Output------ --Sequential Input- --Random-
> --Block-- -Rewrite- ---FS--- --Block-- --Seeks--
> K/sec %CP K/sec %CP K/sec %CP /sec %CP
> Whole disk: 61652 20 15886 4 Reiser 25011 3 250.0 0
> 67212 23 16978 4 Ext3 26842 2 234.5 0
> 68275 24 16198 4 Ext3 28969 3 227.0 0
>
> Partitioned: 57096 19 16218 4 Reiser 23718 3 252.4 0
> 60934 21 15565 3 Ext3 26900 2 228.7 0
> 60866 21 16219 4 Ext3 26272 2 234.2 0
>
> While the results above aren't showing the same kind of drastic
> difference as with the raid array it still seems clear that the
> partitioned drive is slower on average. I'm on 2.6.14 with a Pentium 4
> 3GHz CPU with SMP and Hyperthreading active. Has anyone else seem
> similar results?
>
> Please CC me and Markus on any replies.
>
> Thanks
> Daniel Nilsson
next prev parent reply other threads:[~2005-11-22 15:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-09 18:23 Performance degradation when using partitions Daniel Nilsson
2005-11-22 15:48 ` Bill Davidsen [this message]
2005-11-24 14:08 ` Daniel Nilsson
2005-11-24 18:41 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43833DD9.2060108@tmr.com \
--to=davidsen@tmr.com \
--cc=Markus.Lidel@shadowconnect.com \
--cc=daniel.n.nilsson@home.se \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.