linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michał Sawicz" <michal@sawicz.net>
To: Robin Hill <robin@robinhill.me.uk>
Cc: linux-raid@vger.kernel.org
Subject: Re: Best strategy to incrementally replace smaller HDDs
Date: Fri, 09 Sep 2011 16:20:20 +0200	[thread overview]
Message-ID: <1315578025.14468.18.camel@michal-laptop> (raw)
In-Reply-To: <20110909131351.GA25347@cthulhu.home.robinhill.me.uk>

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

Dnia 2011-09-09, pią o godzinie 14:13 +0100, Robin Hill pisze:
> On Fri Sep 09, 2011 at 12:48:01PM +0200, Michał Sawicz wrote:
> 
> > Hi all, given the configuration below:
> >       * 8 x 1TB HDDs
> >       * 2 x 2TB HDDs
> > 
> From what you cover below, it sounds like you're limited to 10 drives in
> total. Is this the case?
In the long run - yes, but I can have more temporarily. It's just a
physical issue, not controller issue.

> > On which I currently have:
> >       * (10 x 1TB) RAID6 - persistent storage
> >       * (2 x 1TB) system / temporary storage etc.
> > 
> > I want to replace the 1TB drives for 2TB ones on an as-needed basis,
> > what strategy would you recommend?
> > 
> >      1. If I moved to 2TB RAID6 members (using RAID0 on the 1TB drives),
> >         I would need to replace two of the drives just to match current
> >         capacity. Each next 2TB drive would get me 1TB additional
> >         capacity (but actually I'd need to replace two to gain
> >         anything). That sounds to be most future-proof, but most
> >         expensive.
> >      2. If I moved to 2TB RAID5 members, that would reduce redundancy
> >         but replacing just two would gain me 2TB capacity. Most of the
> >         above still applies.
> 
> So, for both of these, you're planning on changing to:
>     * (2 x 1TB) system
>     * (2 x 2TB) + (3 x 1+1TB) persistent storage
Actually no, currently I'm planning to go:
      * (2 x 1TB) system,
      * (4 x 2TB) + (2 x 1+1TB)

So that's 8TB in RAID6, 10TB in RAID5. I already have 8TB and the only
way is up. With RAID6 I'd have to replace at least 4x1TB for 3x2TB
initially (one less drive total).

> This gives you 6TB persistent storage in RAID6, or 8TB in RAID5. As you
> say, replacing 2 1TB drives for 2TB drives (or adding a 2TB drive, if
> possible) would give you 8TB in RAID6 again.
> 
> You'll also need to do a backup, rebuild & restore for either of these
> solutions.
As I mentioned in my previous reply to David, I'm planning to
shrink/grow as needed.

> In either case, replacing a single drive (assuming you're limited in
> total drive count) would not gain any capacity, whereas a pair of drive
> replacements would give you a 2TB increase.
> 
> I'd steer clear of RAID5 with 2TB drives - rebuilding a 2TB drive will
> present a very large window for total array failure.
Yeah, that's why I switched to RAID6 in the first place...

> >      3. If I kept to 1TB RAID6 (two on the 2TB drives), I would reduce
> >         the redundancy to just one drive if it was the 2TB drive that
> >         failed, but each new drive would gain me 1TB capacity and I only
> >         need to replace one-by-one. This sounds like the cheapest, but
> >         worst possible approach.
> > 
> Losing a single 2TB drive would lose 2 partitions, wiping out all
> redundancy. You're only needing to rebuild 1TB before you're back to
> partial redundancy though, so you're less prone to read failures than
> with RAID5 above. A second 2TB drive failure during recovery of either
> partition will cause total array failure though.
> 
> Replacing a single 1TB drive would gain you 1TB in space.
> 
> There's also no need to do a complete wipe & restore - you can just
> replace the drive and recover onto the new one.
> 
> Performance will be worse (particularly during recovery) as you're
> always seeking between the two partitions.
> 
> Personally, I'd go with RAID6 on 2TB partitions. It is more expensive,
> but I think the performance and redundancy benefits outweigh the costs.
That's the direction I'm leaning to as well.

Thanks a lot for the comments!
-- 
Michał (Saviq) Sawicz <michal@sawicz.net>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2011-09-09 14:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 10:48 Best strategy to incrementally replace smaller HDDs Michał Sawicz
2011-09-09 12:34 ` David Brown
2011-09-09 14:12   ` Michał Sawicz
2011-09-09 13:13 ` Robin Hill
2011-09-09 14:20   ` Michał Sawicz [this message]
2011-09-27  8:37     ` Best strategy to incrementally replace smaller HDDs [success story] Michał Sawicz

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=1315578025.14468.18.camel@michal-laptop \
    --to=michal@sawicz.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=robin@robinhill.me.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).