linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).