All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Moshe Yudkowsky <moshe@pobox.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: One Large md or Many Smaller md for Better Peformance?
Date: Sun, 20 Jan 2008 17:18:40 -0500	[thread overview]
Message-ID: <4793C8C0.3010301@tmr.com> (raw)
In-Reply-To: <4793AE0E.609@pobox.com>

Moshe Yudkowsky wrote:
> Question: with the same number of physical drives,  do I get better 
> performance with one large md-based drive, or do I get better 
> performance if I have several smaller md-based drives?
>
> Situation: dual CPU, 4 drives (which I will set up as RAID-1 after 
> being terrorized by the anti-RAID-5 polemics included in the Debian 
> distro of mdadm).
>
> I've two choices:
>
> 1. Allocate all the drive space into a single large partition, place 
> into a single RAID array (either 10 or 1 + LVM, a separate question).
>
One partitionable RAID-10, perhaps, then partition as needed. Read the 
discussion here about performance of LVM and RAID. I personally don't do 
LVM unless I know I will have to have great flexibility of configuration 
and can give up performance to get it. Other report different results, 
so make up your own mind.
> 2. Allocate each drive into several smaller partitions. Make each set 
> of smaller partitions into a separate RAID 1 array and use separate 
> RAID md drives for the various file systems.
>
> Example use case:
>
> While working other problems, I download a large torrent in the 
> background. The torrent writes to its own, separate file system called 
> /foo. If /foo is mounted on its own RAID 10 or 1-LVM array, will that 
> help or hinder overall system responsiveness?
>
> It would seem a "no brainer" that giving each major filesystem its own 
> array would allow for better threading and responsiveness, but I'm 
> picking up hints in various piece of documentation that the 
> performance can be counter-intuitive. I've even considered the 
> possibility of giving /var and /usr separate RAID arrays (data vs. 
> executables).
>
> If an expert could chime in, I'd appreciate it a great deal.
>
>


-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  parent reply	other threads:[~2008-01-20 22:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-20 20:24 One Large md or Many Smaller md for Better Peformance? Moshe Yudkowsky
2008-01-20 21:57 ` Iustin Pop
2008-01-21  3:19   ` Moshe Yudkowsky
2008-01-22  2:32     ` Carlos Carvalho
2008-01-22 11:34       ` Moshe Yudkowsky
2008-01-22 15:17         ` Tomasz Chmielewski
2008-01-22 15:30         ` Bill Davidsen
2008-01-22 15:32         ` Iustin Pop
2008-01-20 22:18 ` Bill Davidsen [this message]
2008-01-21  3:17   ` One Large md or Many Smaller md for Better Performance? Moshe Yudkowsky
2008-01-21 10:41   ` One Large md or Many Smaller md for Better Peformance? Ask Bjørn Hansen

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=4793C8C0.3010301@tmr.com \
    --to=davidsen@tmr.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=moshe@pobox.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.