From: Mario 'BitKoenig' Holbe <Mario.Holbe@TU-Ilmenau.DE>
To: linux-raid@vger.kernel.org
Subject: Re: Need some information and help on mdadm in order to support it on IBM z Systems
Date: Fri, 18 Apr 2008 11:46:23 +0200 [thread overview]
Message-ID: <fu9qlp$iaj$1@ger.gmane.org> (raw)
In-Reply-To: OF759BAE37.32591658-ONC125742D.004F2D87-C125742D.00543FEE@de.ibm.com
Jean-Baptiste Joret <JORET@de.ibm.com> wrote:
> the scenario actually involves simulating a hardware connection issue for
> a few seconds and bring it back online. But once the hardware comes back
> online it is still do not come back into the array an remains marked
> "faulty spare". Moreover, if you then reboot, the mirror comes up and you
> can mount it but it is degraded and my "faulty spare" is now removed:
This is just the normal way md deals with faulty components. And even
more: I personally don't know any (soft or hard) RAID solution that
would automatically try to re-add faulty components back to an array.
I personally would also consider such an automatic re-add a really bad
idea. There was a reason for the component to fail, you don't want to
touch it again without user intervention - it could make things far more
worse (blocking busses, reading wrong data etc.). A user who knows
better can of course trigger the RAID to touch it again - for md it's
just the way you described already: remove the faulty component from the
array and re-add it.
Being more "intelligent" regarding such an automatic re-add would
require a far deeper failure analysis to decide whether it would be safe
to try re-adding it or better leave it untouched. I don't know any
software yet that would be capable to do so.
Afaik, since a little while md contains one such automatism regarding
sector read errors where it automatically tries to re-write this sector
to the failing disk to trigger disk's sector-reallocation. I personally
even consider this behaviour quite dangerous, since there is no
guarantee that this read-error really occured due to a (quite harmless)
single-sector failure and thus, IMHO even there is a chance to make
things more worse by touching the failing disk again per default.
regards
Mario
--
Computer Science is no more about computers than astronomy is about
telescopes. -- E. W. Dijkstra
next prev parent reply other threads:[~2008-04-18 9:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-11 12:28 Need some information and help on mdadm in order to support it on IBM z Systems Jean-Baptiste Joret
2008-04-11 14:39 ` Bill Davidsen
2008-04-14 11:05 ` Jean-Baptiste Joret
[not found] ` <4804F9FD.4070606@tmr.com>
2008-04-16 15:20 ` Jean-Baptiste Joret
2008-04-18 9:46 ` Mario 'BitKoenig' Holbe [this message]
2008-04-18 13:45 ` David Lethe
2008-04-20 13:41 ` Peter Grandi
2008-04-20 16:24 ` David Lethe
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='fu9qlp$iaj$1@ger.gmane.org' \
--to=mario.holbe@tu-ilmenau.de \
--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).