concerning 'optimal' strip size on RAID disks...
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 9 lines · 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.
Quoted 1 line
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?
Quoted 6 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 5 lines
// 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
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs