All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Linda A. Walsh" <xfs@tlinx.org>
To: xfs-oss <xfs@oss.sgi.com>
Subject: concerning 'optimal' strip size on RAID disks...
Date: Fri, 17 Jul 2009 17:33:21 -0700	[thread overview]
Message-ID: <4A611851.8060904@tlinx.org> (raw)


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? 

Would there be a benefit in running a smaller strip size? 

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.

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

But how does one decide a strip size for RAID disks?

What criteria does one use?

Thanks!
-linda


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2009-07-18  0:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-18  0:33 Linda A. Walsh [this message]
2009-07-20 11:12 ` concerning 'optimal' strip size on RAID disks Michael Monnerie

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=4A611851.8060904@tlinx.org \
    --to=xfs@tlinx.org \
    --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.