All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Lethe" <david@santools.com>
To: Andrew Burgess <aab@cichlid.com>,
	linux raid mailing list <linux-raid@vger.kernel.org>
Subject: RE: Adding more drives/saturating the bandwidth
Date: Wed, 1 Apr 2009 10:17:29 -0500	[thread overview]
Message-ID: <F2C688D6A021E34CB81C0E631EF4C0930174657B@34093-C4-EVS1.exchange.rackspace.com> (raw)
In-Reply-To: <1238597796.4604.6.camel@cichlid.com>

> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> owner@vger.kernel.org] On Behalf Of Andrew Burgess
> Sent: Wednesday, April 01, 2009 9:57 AM
> To: linux raid mailing list
> Subject: Re: Adding more drives/saturating the bandwidth
> 
> 
> > >> > Hey guys, How do you know if your machine can handle
> > >> adding some more drives to it? How can you check that there
> > >> is enough BUS IO to handle extra sata cards and also that
> > >> the machine is powerful enough to support say an 8 drive
> > >> raid 5...
> 
> Look at it from the viewpoint of raid performance rather than disk
> performance. How can the throughput be less with more disks?
> 
> So what if your bus bandwidth is saturated now? Then it will be
> saturated with more disks too, but the raid bandwidth should not
> change,
> it's still the saturation bandwidth.
> 
> And if it's not saturated now then the raid throughput will increase
> assuming you can get more disks operating in parallel.
> 
> I'm sure there are corner cases we can nitpick but isn't this correct
> in
> general?
> 
> --
> 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
In grand sense of things, isn't this question rather irrelevant?  The
answer is one of perception.  Would you ask the same question about
whether or not you could add more programs to run and saturating a CPU?
Of course not, the answer is easy. 

If you need the extra disks, then you need more disks because the
applications running on that machine needs more disk space then you have
available.  Your choice is always to free up existing space, add more
disks, or lighten the overhead by moving applications elsewhere ..
assuming overall performance is "satisfactory" in the eyes of the people
who control your budget.

So isn't this all a moot point?  Set a baseline for appropriate
performance before you begin and create a plan in event the updated
hardware config doesn't meet it, then react accordingly.

David



  reply	other threads:[~2009-04-01 15:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26 12:43 Adding more drives/saturating the bandwidth Jon Hardcastle
2009-03-30 15:40 ` Goswin von Brederlow
2009-03-30 16:28   ` Nagilum
2009-03-31  8:23   ` Jon Hardcastle
2009-03-31 13:05     ` Greg Freemyer
2009-03-31 21:07     ` Goswin von Brederlow
2009-04-01  8:15       ` Jon Hardcastle
2009-04-01  8:56       ` Jon Hardcastle
2009-04-01 15:59         ` Goswin von Brederlow
2009-04-01 16:15           ` Greg Freemyer
2009-04-01 14:56       ` Andrew Burgess
2009-04-01 15:17         ` David Lethe [this message]
2009-04-01 18:06         ` Goswin von Brederlow
2009-04-01 18:57           ` Richard Scobie
2009-04-03 20:42             ` Goswin von Brederlow
2009-04-03 21:06               ` Robin Hill

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=F2C688D6A021E34CB81C0E631EF4C0930174657B@34093-C4-EVS1.exchange.rackspace.com \
    --to=david@santools.com \
    --cc=aab@cichlid.com \
    --cc=linux-raid@vger.kernel.org \
    /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.