From: Brian Davis <bridavis@comcast.net>
To: xfs@oss.sgi.com
Subject: Negligible improvement when using su/sw for hardware RAID5, expected?
Date: Fri, 11 Aug 2006 23:10:29 -0400 [thread overview]
Message-ID: <44DD46A5.7010308@comcast.net> (raw)
Is this expected? I thought I would see more improvement when tweaking
my su/sw values for hardware RAID 5.
Details, 3x300GB drives, 3Ware 7506-4LP Hardware RAID 5 using a 64K
stripe size (non-configurable on this card).
FS creation and Bonnie++ results:
Untweaked:----------------------------------------------------------------------
localhost / # mkfs.xfs -f /dev/sda1
meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578999
blks
= sectsz=512 attr=0
data = bsize=4096 blocks=146527968, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=32768, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0
localhost / # mount -t xfs /dev/sda1 /raid
localhost / # cd /raid
localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f
Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Version 1.93c ------Sequential Output------ --Sequential Input-
--Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
localhost 30G 27722 40 23847 37 98367 99
88.6 11
Latency 891ms 693ms 16968us
334ms
Tweaked:-------------------------------------------------------------------------
localhost / # mkfs.xfs -f -d sw=2,su=64k /dev/sda1
meta-data=/dev/sda1 isize=256 agcount=32, agsize=4578992
blks
= sectsz=512 attr=0
data = bsize=4096 blocks=146527744, imaxpct=25
= sunit=16 swidth=32 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=32768, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0
localhost / # mount -t xfs /dev/sda1 /raid
localhost / # cd /raid
localhost raid # bonnie++ -n0 -u0 -r 768 -s 30720 -b -f
Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Version 1.93c ------Sequential Output------ --Sequential Input-
--Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
localhost 30G 27938 43 23880 40 98066 99
91.8 9
Latency 772ms 584ms 19889us
340ms
next reply other threads:[~2006-08-12 3:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-12 3:10 Brian Davis [this message]
2006-08-14 8:51 ` Negligible improvement when using su/sw for hardware RAID5, expected? utz lehmann
2006-08-14 13:29 ` Brian Davis
2006-08-14 15:08 ` Sebastian Brings
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=44DD46A5.7010308@comcast.net \
--to=bridavis@comcast.net \
--cc=xfs@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox