From: David Greaves <david@dgreaves.com>
To: John McMonagle <johnm@advocap.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: Convert raid5 to raid1?
Date: Fri, 11 Mar 2005 08:58:30 +0000 [thread overview]
Message-ID: <42315DB6.5030604@dgreaves.com> (raw)
In-Reply-To: <4230E003.4040609@advocap.org>
John McMonagle wrote:
> Not saying its broke.
good :)
> Part of my reasoning to go to raid5 was that I could expand.
OK that is really quite hard.
Unless you run lvm2 over the top - in which case it's a doddle (though
constraints apply)
I'd do it anyway (run lvm2). It causes almost no performance issues and
you can then grow your fs later.
You could build a raid5 then linearly extend onto a raid0
> While it can be done I don't really see it as practical.
> Also it's looking like I probably will not need to expand.
Oh.
> raid5 with 3 drives and 1 spare
> or 2 - 2 drive raid1 drives have the same space.
> Which is less likely to have a failure cause data loss?
> I'm guessing raid1.
> If I'm wrong I'd like to know now.
A 4x raid5 gives 3X space and survives 1 disk failure (a spare can be
added later)
A 2x raid1/raid0+2 gives 2X space and if 1 disk fails then there's a 1/3
chance that a second failure will cause total failure.
A 3x raid5+1s gives 2X space and the ability for 2 simultaneous* disk
failures
A 4x raid6 gives 2X space and the ability for 2 simultaneous** disk failures
* simultaneous here = apart from the few hours whilst a resync occurs -
really I'm more interested in the lack of resilience during the few
weeks whilst the RMA happens. Although I ended up with a spare 'cos I
waited for a failure and bought a spare on next-day delivery whilst
wrapping the failed disk for RMA
** really simultaneous
>
> Also concerned about the resync times. It was going to take a couple
> days to resync under a rather light load if it weren't for the fact
> that it couldn't because of a bad drive and a kernel panic caused by
> the read error.
Hmm, took a few hours to resync 1Tb here. (maybe as much as overnight)
> Still not certain about the cause of problem my current guess is the
> sata controller.
I run a 7 device SATA and it's81 stable (on 2.6.11.2 now).
I had a few minor problems a few months back but I think they've been
sorted.
> I'm glad there is work being done on the resync issue.
> Also think the ideas to attempt to fix read errors are great.
Yes the "read error = kick disk" is still a significant failing :(
> My only suggestion is that there should be provision to send
> notification when it happens
such as this one:
This is an automatically generated mail message from mdadm
running on cu.dgreaves.com
A Fail event had been detected on md device /dev/md0.
Faithfully yours, etc.
man madm
(or Debian sets it up automagically)
HTH
One other suggestion is to consider using lvm over 2 raid1 devices
rather than md0/md1 - I think you'll find a lot more flexibility there.
David
next prev parent reply other threads:[~2005-03-11 8:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-10 21:38 Convert raid5 to raid1? John McMonagle
2005-03-10 22:34 ` Frank Wittig
2005-03-10 23:04 ` Brad Campbell
2005-03-10 23:13 ` Guy
2005-03-11 0:02 ` John McMonagle
2005-03-11 3:09 ` Guy
2005-03-11 8:58 ` David Greaves [this message]
2005-03-11 0:11 ` Paul Clements
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=42315DB6.5030604@dgreaves.com \
--to=david@dgreaves.com \
--cc=johnm@advocap.org \
--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.