All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: stan@hardwarefreak.com
Cc: vincent Ferrer <vincentchicago1@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: raid5 to utilize upto 8 cores
Date: Fri, 17 Aug 2012 09:29:44 +0200	[thread overview]
Message-ID: <502DF2E8.4030207@hesbynett.no> (raw)
In-Reply-To: <502DEFAB.3060206@hardwarefreak.com>

On 17/08/2012 09:15, Stan Hoeppner wrote:
> On 8/16/2012 2:52 AM, David Brown wrote:
>> For those that don't want to use XFS, or won't have balanced directories
>> in their filesystem, or want greater throughput of larger files (rather
>> than greater average throughput of multiple parallel accesses), you can
>> also take your 5 raid1 mirror pairs and combine them with raid0.  You
>> should get similar scaling (the cpu does not limit raid0).  For some
>> applications (such as mail server, /home mount, etc.), the XFS over a
>> linear concatenation is probably unbeatable.  But for others (such as
>> serving large media files), a raid0 over raid1 pairs could well be
>> better.  As always, it depends on your load - and you need to test with
>> realistic loads or at least realistic simulations.
>
> Sure, a homemade RAID10 would work as it avoids the md/RAID10 single
> write thread.  I intentionally avoided mentioning this option for a few
> reasons:
>
> 1.  Anyone needing 10 SATA SSDs obviously has a parallel workload
> 2.  Any thread will have up to 200-500MB/s available (one SSD)
>      with a concat, I can't see a single thread needing 4.5GB/s of B/W
>      If so, md/RAID isn't capable, not on COTS hardware
> 3.  With a parallel workload requiring this many SSDs, XFS is a must
> 4.  With a concat, mkfs.xfs is simple, no stripe aligning, etc
>      ~$ mkfs.xfs /dev/md0
>

These are all good points.  There is always a lot to learn from your posts.

My only concern with XFS over linear concat is that its performance 
depends on the spread of allocation groups across the elements of the 
concatenation (the raid1 pairs in this case), and that in turn depends 
on the directory structure.  (I'm sure you'll correct me if I'm wrong in 
this - indeed I would /like/ to be wrong!)  If you have large numbers of 
top-level directories and a spread of access, then this is ideal.  But 
if you have very skewed access with most access within only one or two 
top-level directories, then as far as I understand XFS allocation 
groups, access will then be concentrated heavily on only one (or a few) 
of the concat elements.

raid0 of the raid1 pairs may not be the best way to spread out access 
(assuming XFS linear concat is not a good fit for the workload), but it 
might still be an improvement.  Perhaps a good solution would be raid0 
with a very large chunk size - that make most accesses non-striped (as 
you say, the user probably doesn't need striping), thus allowing more 
parallel accesses, while scattering the accesses evenly across all raid1 
elements?


Of course, we are still waiting to hear a bit about the OP's real load.


  reply	other threads:[~2012-08-17  7:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16  2:56 raid5 to utilize upto 8 cores vincent Ferrer
2012-08-16  5:58 ` Stan Hoeppner
2012-08-16  7:03   ` Mikael Abrahamsson
2012-08-16  7:52   ` David Brown
2012-08-16 15:47     ` Flynn
2012-08-17  7:15     ` Stan Hoeppner
2012-08-17  7:29       ` David Brown [this message]
2012-08-17 10:52         ` Stan Hoeppner
2012-08-17 11:47           ` David Brown
2012-08-18  4:55             ` Stan Hoeppner
2012-08-18  8:59               ` David Brown
     [not found]   ` <CAEyJA_ungvS_o6dpKL+eghpavRwtY9eaDNCRJF0eUULoC0P6BA@mail.gmail.com>
2012-08-16  8:55     ` Stan Hoeppner
2012-08-16 22:11   ` vincent Ferrer
2012-08-17  7:52     ` David Brown
2012-08-17  8:29     ` Stan Hoeppner
     [not found] ` <CAD9gYJLwuai2kGw1D1wQoK8cOvMOiCCcN3hAY=k_jj0=4og3Vg@mail.gmail.com>
     [not found]   ` <CAEyJA_tGFtN2HMYa=vDV7m9N8thA-6MJ5TFo20X1yEpG3HQWYw@mail.gmail.com>
     [not found]     ` <CAD9gYJK09kRMb_v25uwmG7eRfFQLQyEd4SMXWBSPwYkpP56jcw@mail.gmail.com>
2012-08-16 21:51       ` vincent Ferrer
2012-08-16 22:29         ` Roberto Spadim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=502DF2E8.4030207@hesbynett.no \
    --to=david.brown@hesbynett.no \
    --cc=linux-raid@vger.kernel.org \
    --cc=stan@hardwarefreak.com \
    --cc=vincentchicago1@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.