From: Bernd Schubert <bs@q-leap.de>
To: linux-raid@vger.kernel.org, linux-hotplug-devel@lists.sourceforge.net
Subject: removed disk && md-device
Date: Wed, 09 May 2007 12:17:08 +0000 [thread overview]
Message-ID: <200705091417.09033.bs@q-leap.de> (raw)
Hi,
we are presently running into a hotplug/linux-raid problem.
Lets assume a hard disk entirely fails or a stupid human being pulls it out of
the system. Several partitions of the very same hardisk are also part of
linux-software raid. Also, /dev is managed by udev.
Problem-1) When the disk fails, udev will remove it from /dev. Unfortunately
this will make it impossible to remove the disk or its partitions
from /dev/mdX device, since mdadm tries to read the device fail and will
abort if this file is not there.
Problem-2) Even though the kernel detected the device to not exist anymore, it
didn't inform its md-layer about this event. The md-layer will first detect
non-existent disk, if a read or write attempt to one of its raid-partitions
fails. Unfortunately, if you are unluckily, it might never detect that, e.g.
for raid1 devices.
I think there should be several solutions to these problems.
1) Before udev removes a device file, it should run a pre-remove script, which
should check if the device is listed in /proc/mdstat and if it is listed
there, it should run mdadm to remove this device from the.
Does udev presently support to run pre-remove scripts?
2.) As soon as the kernel detects a failed device, it should also inform the
md layer.
3.) Does mdadm really need the device?
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
WARNING: multiple messages have this Message-ID (diff)
From: Bernd Schubert <bs@q-leap.de>
To: linux-raid@vger.kernel.org, linux-hotplug-devel@lists.sourceforge.net
Subject: removed disk && md-device
Date: Wed, 9 May 2007 14:17:08 +0200 [thread overview]
Message-ID: <200705091417.09033.bs@q-leap.de> (raw)
Hi,
we are presently running into a hotplug/linux-raid problem.
Lets assume a hard disk entirely fails or a stupid human being pulls it out of
the system. Several partitions of the very same hardisk are also part of
linux-software raid. Also, /dev is managed by udev.
Problem-1) When the disk fails, udev will remove it from /dev. Unfortunately
this will make it impossible to remove the disk or its partitions
from /dev/mdX device, since mdadm tries to read the device fail and will
abort if this file is not there.
Problem-2) Even though the kernel detected the device to not exist anymore, it
didn't inform its md-layer about this event. The md-layer will first detect
non-existent disk, if a read or write attempt to one of its raid-partitions
fails. Unfortunately, if you are unluckily, it might never detect that, e.g.
for raid1 devices.
I think there should be several solutions to these problems.
1) Before udev removes a device file, it should run a pre-remove script, which
should check if the device is listed in /proc/mdstat and if it is listed
there, it should run mdadm to remove this device from the.
Does udev presently support to run pre-remove scripts?
2.) As soon as the kernel detects a failed device, it should also inform the
md layer.
3.) Does mdadm really need the device?
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
next reply other threads:[~2007-05-09 12:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-09 12:17 Bernd Schubert [this message]
2007-05-09 12:17 ` removed disk && md-device Bernd Schubert
2007-05-09 13:14 ` martin f krafft
2007-05-09 13:14 ` martin f krafft
2007-05-09 13:39 ` Bernd Schubert
2007-05-09 13:39 ` Bernd Schubert
2007-05-10 7:12 ` Neil Brown
2007-05-10 7:12 ` Neil Brown
2007-05-10 14:33 ` David Greaves
2007-05-10 14:33 ` David Greaves
2007-05-11 1:36 ` Neil Brown
2007-05-11 1:36 ` Neil Brown
2007-05-11 8:51 ` Michael Tokarev
2007-05-11 8:51 ` Michael Tokarev
2007-05-11 9:22 ` Bernd Schubert
2007-05-11 9:22 ` Bernd Schubert
2007-05-11 20:39 ` Bill Davidsen
2007-05-11 20:39 ` Bill Davidsen
2007-05-15 9:52 ` Goswin von Brederlow
2007-05-15 9:52 ` Goswin von Brederlow
2007-05-11 8:52 ` David Greaves
2007-05-11 8:52 ` David Greaves
2007-05-11 15:05 ` David Greaves
2007-05-11 15:05 ` David Greaves
2007-05-11 20:50 ` David Greaves
2007-05-11 20:50 ` David Greaves
2007-05-10 18:17 ` Bernd Schubert
2007-05-10 18:17 ` Bernd Schubert
2007-05-11 6:16 ` Neil Brown
2007-05-11 6:16 ` Neil Brown
2007-05-11 20:47 ` Bill Davidsen
2007-05-11 20:47 ` Bill Davidsen
2007-05-16 21:19 ` Colin McCabe
2007-05-16 21:19 ` Colin McCabe
2007-05-09 21:41 ` Michael Tokarev
2007-05-09 21:41 ` Michael Tokarev
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=200705091417.09033.bs@q-leap.de \
--to=bs@q-leap.de \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.