[email protected]
[Top] [All Lists]

Bug#416512: marked as forwarded (Failures with hotplugging)

Subject: Bug#416512: marked as forwarded Failures with hotplugging
From: Debian Bug Tracking System
Date: Sat, 31 Mar 2007 10:18:09 +0000
Your message dated Sat, 31 Mar 2007 12:16:50 +0200
with message-id <[email protected]>
has caused the Debian Bug report #416512,
regarding Failures with hotplugging
to be marked as having been forwarded to the upstream software
author(s) [email protected]

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Subject: Fwd: Failures with hotplugging
From: martin f krafft
Date: Sat, 31 Mar 2007 12:16:50 +0200
tags 416512 upstream

Neil, this also looks like a job for upstream. :)

----- Forwarded message from Goswin von Brederlow 
<[email protected]> -----

Date: Wed, 28 Mar 2007 16:06:43 +0200
From: Goswin von Brederlow <[email protected]>
To: Debian Bug Tracking System <[email protected]>
Subject: Failures with hotplugging
X-Mailer: reportbug 3.31

Package: mdadm
Version: 2.5.6-9
Severity: normal


I have problems with the mdadm and software raid behaviour in Linux.

I have a kernel with a Marvell SATA controler with the extra
marvell driver (mv_sata not sata_mv) for hotplug support. I have 2
disks (sda1+sdb1) in a software raid1 connected to it.

The problem comes when I hot-remove a disk (sdb) from the
hardware. The marvell controler sees the removal and removed the disk
from the system. The scsi layer gives a cache flush failure on sdb
(expected), sysfs removes /sys/block/sdb/(sdb1/) and udev removes
/dev/sdb(1). So far so good.

The raid does no mark /dev/sdb1 as failed or even removed. Only on the
next access it gets an I/O error and marks it.

'mdadm --fail /dev/md0 /dev/sdb1' tries to stat /dev/sdb1 [Manage.c:
Manage_subdevs(): 189] and gives an error. Same for --remove. The
device can not be removed without first manually recreating the device
node. Note that /sys/block/md0/md/dev-sdb1/block is a broken symlink
at this point and /sys/block/md0/md/dev-sdb1/block/dev can't be used
to find the major/minor of the device.

Reinserting the disk will cause a new device minor to be allocated and
the disk reappears as /dev/sdc. Given that the software raid still
things sdb1 is valid (unless written too) this is a good thing. It
shows that somewhere in the kernel it still knows sdb is in use.

mdadm should be able to fail/remove an unplugged disk but I don't know
where mdadm should get the device infos for it at this point.

And it would be nice if the kernel would tell the software raid that
the device was removed and set it failed automatically. But that
probably needs another bug.


-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

----- End forwarded message -----

martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; [email protected]
spamtraps: [email protected]
"den stil verbessern, das heißt den gedanken verbessern."
                                                 - friedrich nietzsche

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
  • Bug#416512: marked as forwarded (Failures with hotplugging), Debian Bug Tracking System <=