Elevator...  If the RAID _controller_ does the Elevator stuff, any OS 
optimizations are wasted.
And there have been benchmarks backing that up.  (Sorry, don't have any links 
handy.)

RAID 5/10 ...  The testing I have done shows very little difference.  However, 
you can slant the conclusion by picking one versus the other of:
"For a given amount of disk space... RAID-X is better than Y."
"For a given number of drives...     RAID-Y is better than X."

When writing a random block, RAID-5 does not need to touch all the drives, only 
the one with parity.  Suitable XORs will update it correctly.  So, a write hits 
2 drives, whether you have RAID-5 or -10.

Some people make the chunk size 64KB (etc); not 512B.  With the Controller 
involved, there is not necessarily any benefit for large vs small chunk size.  
Writes are delayed until the it is optimal.  This leads to large streaming 
writes to each drive, regardless of chunk size (when writing a large stream).

A heavily used InnoDB system will be writing random 16KB blocks.

(I have no insight into RAID-6.)

> -----Original Message-----
> From: Johan De Meersman [mailto:vegiv...@tuxera.be]
> Sent: Monday, July 29, 2013 3:38 PM
> To: Rick James; will...@techservsys.com; mysql@lists.mysql.com
> Subject: RE: hypothetical question about data storage
> 
> Rick James <rja...@yahoo-inc.com> wrote:
> >
> >For MySQL + RAID, a Linux elevator strategy of 'deadline' or 'noop' is
> >optimal.  (The default, 'cfq', is not as good.)
> 
> I should look into those again at some point. Do you have a brief word as
> to why they're better?
> 
> 
> >A RAID controller with multiple drives striped (and optionally
> >parity-checked) (RAID-5, -10) and with a BBU (Battery Backed Write
> >Cache) is excellent for I/O.
> 
> Very true. 10 is traditionally considered better - it's certainly faster -
> but 5 is of course cheaper :-)
> 
> I'd like to add that 4+1 is the optimal configuration for RAID5 , as that
> makes for a stripe of 2kb, assuming 512b sectors of course. You then pick
> an fs that supports blocks of that size , which means that no write will
> ever need to perform a read first to calculate the checksum.
> 
> 
> 
> 
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Reply via email to