concerning 'optimal' strip size on RAID disks...

concerning 'optimal' strip size on RAID disks...

[Linda A. Walsh]

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

Re: concerning 'optimal' strip size on RAID disks...

[Michael Monnerie]

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