Exercise 3: Pulling a Disk Without Running mdadm Commands First — Possible Solution
====================================================================

Why this is risky:

Per the chapter's own warn-box, "Physically removing a disk from a
live array before both --fail and --remove have been run against it
leaves Linux potentially still attempting I/O against a device that's
already physically gone -- a real path to an unclean array state and
additional corruption risk, on top of whatever originally prompted the
disk's removal." The administrator's disk was showing signs of failure
but had not yet been marked as failed or removed from the array's own
bookkeeping -- as far as mdadm and the kernel are concerned, that disk
was still an active, in-use member of the array right up until it was
physically yanked out. If the array (or the filesystem/application on
top of it) was in the middle of any I/O operation involving that
disk at the exact moment it was pulled, that operation has no clean
way to complete or fail gracefully -- the device simply vanished out
from under it, which is a fundamentally different, less controlled
situation than mdadm being told in advance "this disk is failed, stop
using it."

This adds a real, additional corruption risk on top of whatever
originally made the disk look like it was failing -- the pre-existing
warning signs on the disk are one problem; an uncontrolled mid-I/O
removal is a second, separate problem layered on top of it.

The correct sequence:

Per the chapter's own worked example, the correct order is:
mdadm /dev/md0 --fail /dev/sdX1 (tell mdadm to stop using the disk and
treat it as failed), then mdadm /dev/md0 --remove /dev/sdX1 (formally
remove it from the array's own membership), and only THEN physically
pull the disk from the running server -- at which point mdadm already
considers it gone and isn't attempting any I/O against it. Only after
the physical replacement is installed would mdadm /dev/md0 --add
/dev/sdX1 bring the new disk in and trigger the rebuild.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the actual danger (uncontrolled I/O against a device
that vanished mid-operation, vs. mdadm being told in advance to stop
using it) rather than just citing the rule, and gives the specific
correct command sequence the chapter itself demonstrates.