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 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.