Stupid question regarding RAID-1 access pattern
Tried to ferret out the answer to this myself and so far so bad.
This just 'popped in there' while I was optimizing something completely different... in a RAID-1, writes have to be mirrored of course, thats what RAID-1 is, but for reads, could they not be sped up by a significant amount if a storage pattern was chosen such that large blocks of data were "striped" in an in-order/out-of-order scheme? In other words, store all the data on both drives, but in huge (2x cache size) -ish blocks that might allow 50% of a given [large] access to come from each drive, with trivial [smaller] reads always coming from one or the other chosen at random.
Downside, I know, is that the data would be organized ina way only the raid subsystem would understand, so the niceness of pulling a mirrored drive out of service and it being a literal copy of the otehr drive would be lost, but for such a speedup I'd be willing to pay the price of always having to access it as a failed set (worst case) through the md-daemon.
Am I off into the weeds?
-Curt
Quoted 12 lines · Curt Hartung
Tried to ferret out the answer to this myself and so far so bad.
This just 'popped in there' while I was optimizing something completely different... in a RAID-1, writes have to be mirrored of course, thats what RAID-1 is, but for reads, could they not be sped up by a significant amount if a storage pattern was chosen such that large blocks of data were "striped" in an in-order/out-of-order scheme? In other words, store all the data on both drives, but in huge (2x cache size) -ish blocks that might allow 50% of a given [large] access to come from each drive, with trivial [smaller] reads always coming from one or the other chosen at random.
Quoted 8 lines
Downside, I know, is that the data would be organized ina way only the raid subsystem would understand, so the niceness of pulling a mirrored drive out of service and it being a literal copy of the otehr drive would be lost, but for such a speedup I'd be willing to pay the price of always having to access it as a failed set (worst case) through the md-daemon.
Am I off into the weeds?
I doubt this would help much really. If you're reading sequential data then it's pretty much as quick to keep reading as to seek to the next chunk. If you want a performance and are prepared to throw out strict RAID1 compatibility then RAID10-f2 may be better suited. It still provides the same redundancy but improves read performance by striping (there's some slowdown on writes but not much).
Cheers,
Robin
Signature · 4 lines
___
( ' } | Robin Hill <[email protected]> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |Quoted 3 lines · Robin Hill
I doubt this would help much really. If you're reading sequential data then it's pretty much as quick to keep reading as to seek to the next chunk.
Could it hurt [performance]? SSDs will only become more common, and they haven't any seek penalty.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Billy Crook
Quoted 3 lines · Robin Hill
I doubt this would help much really. If you're reading sequential data then it's pretty much as quick to keep reading as to seek to the next chunk.
Could it hurt [performance]? SSDs will only become more common, and they haven't any seek penalty.
Probably not, with SSDs, but we've already got RAID10 which, if I'm not mistaken, does pretty much what you're describing (if not, can you provide some diagrams of what the layout you're thinking of would look like).
Cheers,
Robin
Signature · 4 lines
___
( ' } | Robin Hill <[email protected]> |
/ / ) | Little Jim says .... |
// !! | "He fallen in de water !!" |Quoted 3 lines · Robin Hill
I doubt this would help much really. If you're reading sequential data then it's pretty much as quick to keep reading as to seek to the next chunk.
Only if your stripe size is smaller than your bandwidth x seek time. Break even stripe size for 100MB/s 10ms disks would be 1 MB, so it might work well with 4-10 MB stripes provided the IO stack is up to it?
Erno
Quoted 12 lines · Erno Kuusela
Quoted 4 lines · Robin Hill
I doubt this would help much really. If you're reading sequential data then it's pretty much as quick to keep reading as to seek to the next chunk.
Only if your stripe size is smaller than your bandwidth x seek time. Break even stripe size for 100MB/s 10ms disks would be 1 MB, so it might work well with 4-10 MB stripes provided the IO stack is up to it?
10ms is the full stroke seek time, I suspect for smaller chunks/seeks the time would be *much* shorter...
Quoted 21 lines
-----Original Message-----
From: [email protected] [mailto:linux-raid- [email protected]] On Behalf Of Curt Hartung
Sent: Wednesday, January 06, 2010 1:58 PM
To: [email protected]
Subject: Stupid question regarding RAID-1 access patternTried to ferret out the answer to this myself and so far so bad.
This just 'popped in there' while I was optimizing something completely different... in a RAID-1, writes have to be mirrored of course, thats what RAID-1 is, but for reads, could they not be sped up by a significant amount if a storage pattern was chosen such that large blocks of data were "striped" in an in-order/out-of-order scheme? In other words, store all the data on both drives, but in huge (2x cache size) -ish blocks that might allow 50% of a given [large] access to come from each drive, with trivial [smaller] reads always coming from one or the other chosen at random.
Quoted 8 lines
Downside, I know, is that the data would be organized ina way only the raid subsystem would understand, so the niceness of pulling a mirrored drive out of service and it being a literal copy of the otehr drive would be lost, but for such a speedup I'd be willing to pay the price of always having to access it as a failed set (worst case) through the md-daemon.
Am I off into the weeds?
I think either you may be expressing yourself incorrectly, or else
you are not thinking through the process. If both drive are identical in type, then reading from either one is going to take the same amount of time. If one drive is inherently slower than the other, then one may employ the write-mostly parameter of RAID so that it generally only reads from the faster drive. The only performance benefit would be observed by performing ordered non-sequential seeks on alternate drives, and I believe md already does that. There is no benefit gained to set up a formal "stripe" architecture, but, for example, if the system calls for seeks to cylinders 1000, 1001, 1002, 1003, 768, 769, and 770, then the best performance would be gained by issuing seeks to 1000 - 1003 on one drive and 768 - 770 on the other.