[mythtv-users] Question re: available SATA ports and linux software RAID

Robin Hill myth at robinhill.me.uk
Tue Apr 12 15:13:03 UTC 2011

On Tue Apr 12, 2011 at 03:25:11PM +0100, Simon Hobson wrote:

> Ian Clark wrote:
> >Apologies if my explanation isn't very clear, it makes my head spin a
> >bit too I'm afraid.
> Quite clear - it's a case of arranging that OS chunks match stripes 
> in the array so that when the OS write out a chunk, it will be a full 
> stripe of the array and so just be a write to all drives without 
> needing to read data first to calculate a new parity block.
> Though the technicalities of working out the chunk size in the FS is 
> beyond me at the moment !
No, the stripe size must be a multiple of the FS block size - this is 1,
2 or 4k for ext2/3/4 (depending on FS size) and defaults to 4k for XFS
(generally this maxes at the memory pagesize, which is 4k for
x86/x86-64). So making the array chunk size a multiple of 4k (default is
512k for current mdadm - older versions used 64k I think) will mean the
stripe width is irrelevant (so powers of 2 don't come into it at all).

It's then up to the md driver to try to write complete stripes
(providing enough sequential data is available) .

In other words, this should be working optimally out of the box, and
there's little you can do to help/hinder it (increasing the
stripe_cache_size for RAID5/6 can help, but at the cost of increased
memory usage).

The other issue (that Ian seems to have had previously) is that
partitioned arrays need to be arranged so that partitions fall on stripe
boundaries. I wouldn't use a partitioned array anyway - partitioning
first, then making multiple arrays seems more sensible to me.

    ( ' }     |       Robin Hill        <myth at robinhill.me.uk>  |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110412/6b3e1de4/attachment.bin 

More information about the mythtv-users mailing list