Stupid question regarding RAID-1 access pattern

Stupid question regarding RAID-1 access pattern

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

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

Re: Stupid question regarding RAID-1 access pattern

[Robin Hill]

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

Re: Stupid question regarding RAID-1 access pattern

[Billy Crook]

On Wed, Jan 6, 2010 at 15:37, Robin Hill <robin@robinhill.me.uk> wrote:
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Stupid question regarding RAID-1 access pattern

[Robin Hill]

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

On Wed Jan 06, 2010 at 04:13:55PM -0600, Billy Crook wrote:

> On Wed, Jan 6, 2010 at 15:37, Robin Hill <robin@robinhill.me.uk> wrote:
> > 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
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

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

Re: Stupid question regarding RAID-1 access pattern

[Erno Kuusela]

Robin Hill <robin@robinhill.me.uk> writes:

> 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

Re: Stupid question regarding RAID-1 access pattern

[Asdo]

Erno Kuusela wrote:
> Robin Hill <robin@robinhill.me.uk> writes:
>
>   
>> 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...

RE: Stupid question regarding RAID-1 access pattern

[Leslie Rhorer]

> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Curt Hartung
> Sent: Wednesday, January 06, 2010 1:58 PM
> To: linux-raid@vger.kernel.org
> Subject: 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?

	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.