All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Hill <robin@robinhill.me.uk>
To: linux raid mailing list <linux-raid@vger.kernel.org>
Subject: Re: Adding more drives/saturating the bandwidth
Date: Fri, 3 Apr 2009 22:06:49 +0100	[thread overview]
Message-ID: <20090403210649.GA12384@cthulhu.home.robinhill.me.uk> (raw)
In-Reply-To: <87d4btjwpf.fsf@frosties.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Fri Apr 03, 2009 at 10:42:20PM +0200, Goswin von Brederlow wrote:

> Richard Scobie <richard@sauce.co.nz> writes:
> 
> > Goswin von Brederlow wrote:
> >
> >>
> >> Now think about the same with 6 disk raid5. Suddenly you have partial
> >> stripes. And the alignment on stripe boundaries is gone too. So now
> >> you need to read 384k (I think) of data, compute or delta (whichever
> >> requires less reads) the parity and write back 384k in 4 out of 6
> >> cases and read 64k and write back 320k otherwise. So on average you
> >> read 277.33k and write 362.66k (= 640k combined). That is twice the
> >> previous bandwidth not to mention the delay for reading.
> >>
> >> So by adding a drive your throughput is suddenly halfed. Reading in
> >> degraded mode suffers a slowdown too. CPU goes up too.
> >>
> >>
> >> The performance of a raid is so much dependent on its access pattern
> >> that imho one can not talk about a general case. But note that the
> >> more drives you have the bigger a stripe becomes and you need larger
> >> sequential writes to avoid reads.
> >
> > I take your point, but don't filesystems like XFS and ext4 play nice
> > in this scenario by combining multiple sub-stripe writes into stripe
> > sized writes out to disk?
> >
> > Regards,
> >
> > Richard
> 
> Some FS have a parameter to tune to the stripe size. If that actually
> helps or not I leave for you to test.
> 
> But ask yourself: Have any a tool to retune after you've grown the raid?
> 
Both XFS and ext2/3 (and presumably 4 as well) allow you to alter the
stripe size after growing the raid (ext2/3 via tune2fs and XFS via mount
options).  No idea about other filesystems though.

Cheers,
    Robin
-- 
     ___        
    ( ' }     |       Robin Hill        <robin@robinhill.me.uk> |
   / / )      | Little Jim says ....                            |
  // !!       |      "He fallen in de water !!"                 |

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

      reply	other threads:[~2009-04-03 21:06 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
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 [this message]

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=20090403210649.GA12384@cthulhu.home.robinhill.me.uk \
    --to=robin@robinhill.me.uk \
    --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.