Re: Stupid question regarding RAID-1 access pattern

[Robin Hill <robin@robinhill.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

On Wed Jan 06, 2010 at 02:58:16PM -0500, Curt Hartung wrote:

> 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?
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
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]