From: Phillip Susi <psusi@cfl.rr.com>
To: Doug Ledford <dledford@redhat.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: safe segmenting of conflicting changes
Date: Mon, 26 Apr 2010 14:43:58 -0400 [thread overview]
Message-ID: <4BD5DEEE.7020208@cfl.rr.com> (raw)
In-Reply-To: <4BD5D5F7.208@redhat.com>
On 4/26/2010 2:05 PM, Doug Ledford wrote:
> So, the point of raid is to be as reliable as possible, if the disk that
> was once gone is now back, we want to use it if possible.
No, we don't. I explicitly removed that disk from the array because I
have no wish for it to be there any more. Maybe I plan on using it in
another array, or maybe I plan on shreding its contents. Whatever I'm
planning for that disk, it does not involve it being used in a raid
array any more.
> The problem is the cause of this thread, and it's a bug that should be
> fixed, it should not cause us to require things to have an explicit
> --add --force to use a previously failed drive. This is a case of
Then when the drive fails it should only be marked as failed, not also
removed. If I manually remove it, then it should stay removed until I
decide to do something else with it.
> The md raid stack makes no distinction between explicit removal or a
> device that disappeared because of a glitch in a USB cable or some such.
> In both cases the drive is failed and removed. So the fact that you
Then that's the problem. If it fails, it should be marked as failed.
If it is removed, it should be marked as removed. They are two
different actions, that should have different results. Why on earth the
two flags seem to always be used together is beyond me.
next prev parent reply other threads:[~2010-04-26 18:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-23 13:42 safe segmenting of conflicting changes (was: Two degraded mirror segments recombined out of sync for massive data loss) Christian Gatzemeier
2010-04-23 15:08 ` Phillip Susi
2010-04-23 18:18 ` Phillip Susi
2010-04-26 16:59 ` safe segmenting of conflicting changes Doug Ledford
2010-04-26 17:48 ` Phillip Susi
2010-04-26 18:05 ` Doug Ledford
2010-04-26 18:43 ` Phillip Susi [this message]
2010-04-26 19:07 ` Doug Ledford
2010-04-26 19:38 ` Phillip Susi
2010-04-26 23:33 ` Doug Ledford
2010-04-27 16:20 ` Phillip Susi
2010-04-27 17:27 ` Doug Ledford
2010-04-27 18:04 ` Phillip Susi
2010-04-27 19:29 ` Doug Ledford
2010-04-28 13:22 ` Phillip Susi
2010-04-23 21:04 ` safe segmenting of conflicting changes, and hot-plugging between alternative versions Christian Gatzemeier
2010-04-24 8:10 ` Christian Gatzemeier
2010-04-26 17:11 ` Doug Ledford
2010-04-26 21:10 ` Christian Gatzemeier
2010-05-05 11:28 ` detecting segmentation / conflicting changes Christian Gatzemeier
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=4BD5DEEE.7020208@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=dledford@redhat.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 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).