(Adding Tejun & Greg KH to this thread)

Leon Woestenberg wrote:

Hello all,

I am testing the (work-in-progress / upcoming) libata SATA hotplug.
Hotplugging alone seems to work, but not well in combination with md

Here is my report and a question about intended behaviour. Mainstream kernel patched with libata-tj- from

Supermicro P8SCT motherboard with Intel ICH6R, using AHCI libata driver.

In short, I use ext3 over /dev/md0 over 4 SATA drives /dev/sd[a-d]
each driven by libata ahci. I unplug then replug the drive that is
rebuilding in RAID-5.

When I unplug a drive, /dev/sda is removed, hotplug seems to work to
the point where proc/mdstat shows the drive failed, but not removed.

Every other notion of the drive (in kernel and udev /dev namespace)
seems to be gone after unplugging. I cannot manually removed the drive
using mdadm, because it tells me the drive does not exist.

Replugging the drive brings it back as /dev/sde, md0 will not pick it up.

I have a similar setup, AHCI + 4 drives but using a RAID-1 group. The thing that you are looking for is "persistent device naming" and should work properly if you can tweak udev/hotplug correctly.

I have verified that a drive pull/drive reinsert on a mainline kernel with a SLES10 base does provide this (first insertion gives me sdb, pull followed by reinsert still is sdb), but have not tested interaction with RAID since I am focused on the bad block handling at the moment. I will add this to my list ;-)

The expected behaviour (from me) is that the drive re-appears as /dev/sda.

What is the intended behaviour of md in this case?

Should some user-space application fail-remove a drive as a pre-action
of the unplug event from udev, or should md fully remove the drive
within kernel space??

See kernel/udev/userspace messages in chronological order,
with my actions marked between >>> <<<, at this web



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

Reply via email to