linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Christian Gatzemeier <c.gatzemeier@tu-bs.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: "failed" vs "released" and "locked-out" state and --incremental auto-re-adding
Date: Tue, 27 Apr 2010 11:45:46 -0400	[thread overview]
Message-ID: <4BD706AA.9090404@redhat.com> (raw)
In-Reply-To: <loom.20100427T113838-836@post.gmane.org>

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

On 04/27/2010 06:13 AM, Christian Gatzemeier wrote:
> 
> Thanks you for responding and adding insight.
> 
> Doug Ledford <dledford <at> redhat.com> writes:
>> On 04/26/2010 06:28 PM, Christian Gatzemeier wrote:
>>> 2) To "unbind", "unlist" or "dismiss" a member from the md device stats is
>>> currently called to --remove it. In particular you can "unbind", "unlist"
>>> or "dismiss" failed or detatched members with --remove failed/detached.
>>
>> You can use --remove failed/detached/≤devname>, they all work.  But yes,
>> the underlying action here is to take an already failed device go ahead
>> and release
> 
> There we have a very good word to name --remove so that mdadm is easier to
> understand (IMHO). "release"

You're probably right, but it's also too late to change it now :-(
Remove has been in use for quite some time and there are untold numbers
of programs and scripts that use it as it is so that it would be very
difficult to change it.

>> No, and this is a safety feature.  We won't remove a good device in
>> order to prevent a typo from rendering an array dead.
> 
> I understand, makes sense to me.
> Ok, if mdadm --remove (release) could give a little hint to --fail first, if
> "device is busy", it may be able save some head scratches. ;)

Very valid request.

>>> I am unclear why --incremental seems to require a device to be
>>>  --removed (released) first
>>
>> It would be kind of useless to put that support into incremental.
>> Incremental isn't really intended to be run from the command line
>> (although you can), it's intended to be done on hotplug events.
> 
> That is exactly were I encountered this. Unplugging a failed disk, and
> plugging it back in again would fail, unless I manually --remove (released)
> the device before plugging it back in.
> 
> But I think the hot-unplugging support you added will probably fix this in
> the future even nicer. (Automatically releasing devices as soon as they are
> detached.)

Yep, the hot unplug support solves this issue quite nicely.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2010-04-27 15:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23 12:20 "failed" vs "removed" or "locked-out" state and --incremental auto-re-adding Christian Gatzemeier
2010-04-23 14:46 ` Phillip Susi
2010-04-26 22:28 ` &quot;failed&quot; vs &quot;removed&quot; or &quot;locked-out&quot; " Christian Gatzemeier
2010-04-26 23:15   ` Doug Ledford
2010-04-27 10:13     ` "failed" vs "released" and "locked-out" " Christian Gatzemeier
2010-04-27 15:45       ` Doug Ledford [this message]
2010-04-27 19:39         ` 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=4BD706AA.9090404@redhat.com \
    --to=dledford@redhat.com \
    --cc=c.gatzemeier@tu-bs.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).