From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: concerning 'optimal' strip size on RAID disks...
Date: Mon, 20 Jul 2009 13:12:05 +0200 [thread overview]
Message-ID: <200907201312.10058@zmi.at> (raw)
In-Reply-To: <4A611851.8060904@tlinx.org>
[-- Attachment #1.1: Type: text/plain, Size: 2565 bytes --]
On Samstag 18 Juli 2009 Linda A. Walsh wrote:
> Concerning strip-size. What are the considerations for that? Any
> reason not to chose the largest? Seems that at sizes up to 1MB, the
> larger the better.
>
> For direct I/O (which is what the RAID controller would be doing to
> it's disks, seems a larger write would be better).
>
> Would I be naïve to assume that if a RAID controller only needed to
> update 1 block, it wouldn't need to update the entire strip?
I'd say exactly your last sentence tells you why a smaller stripe size
can be better.
> Would there be a benefit in running a smaller strip size?
If you run virtualization (say 20 virtual servers on a single hardware),
you will basically only have random I/O. Each of those 20 servers might
have sequential I/O, but the RAID controller sees 20 streams of I/O,
making the whole thing quite random.
Has anyone benchmarked on this?
> I know when I can control the hard disks, I can enable their write
> caches, so having them do physical writes the keep their write
> buffers saturated would optimize write performance, at least, but if
> it's a BIOS or hardware controlled RAID, I don't know if I'd have the
> option to turn the disk's write buffer on or off. So that likely
> wouldn't matter much.
That setting should be possible via the RAID controller. On Areca you
can set "Disk Write Cache Mode" to off, on HP it's called "write
through" or "write back disabled" IIRC.
> Ideally, I think, it be optimal if a RAID controller (hardware or
> software) really knew the the layout of the data on disk -- as in
> sectors/track.
On today's hardware that's not needed anymore, as already a simple RAID
level virtualizes accesses.
> Then it really might be able to interleave tracks
> among disk units (unless all the tracks can be written contiguously
> w/no delay, then I'd guess there'd be no benefit...oh well..
Yeah, I'm so old that twenty years ago I really still learned that at
school, but those really don't matter anymore.
> But how does one decide a strip size for RAID disks?
> What criteria does one use?
If someone *really* knows, I'd be interested as well.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2009-07-20 11:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-18 0:33 concerning 'optimal' strip size on RAID disks Linda A. Walsh
2009-07-20 11:12 ` Michael Monnerie [this message]
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=200907201312.10058@zmi.at \
--to=michael.monnerie@is.it-management.at \
--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