"failed" vs "released" and "locked-out" state and --incremental auto-re-adding

[Christian Gatzemeier <c.gatzemeier@tu-bs.de>]

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"



> > 3) A safe way to "lock-out" or "really remove" members from
> > udev/--incremental assembly is not available yet AFAIK.
> > (--zero-superblock on mirror members makes the md device content
> >  detectable/available directly)
> 
> This is a shortcoming of version 0.90/1.0 superblocks and raid1 arrays.
>  For all other superblock versions and raid types, this is not true.
> The default superblock version changed from 0.90 to 1.2 as of the mdadm
> 3.1 series and so this won't be a problem in the future.

Good, that'll fix the problem with --zero-superblock for the future.

An explicit "locked-out" state without killing the superblock may still be
good. (Even if only for pausing or optionally auto-locking out detected
alternative versions.)



 
> > IMHO the ones mentioned first could seen as implied by those mentioned
> > later.
> 
> 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. ;)



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



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html