Hi,
My name is Jean-Gabriel Rican and I have a kernel problem.
There is a slight limitation in the Multiple Devices driver that I would
like to address here.
Suppose you can hot-swap a hard disk in a system.
Now if you have a degraded Software RAID device (for example a RAID-5 with
one disk failed) and you replace the failed disk on-the-fly you cannot
start reconstruction (with raidhotadd) of the Software RAID device with
the replaced disk because it says it is BUSY.
The solution is to stop the RAID device (raidstop) and [re-]start it with
(raidstart).
This is an inconvenient because if the RAID device is mounted somewhere it
should be first umounted before stopping, user access to the device would
be interrupted and so on. And it is even worse when the RAID has the root
file system on it and you cannot umount it.
My solution and patch to the kernel driver md.c is to remove the drive
from the RAID array if it is faulty and then import it later.
I tested it thoroughly and it seems to work well.
Kernel version is 2.4.12 (latest).
So I submit this patch and hope that it will be accepted.
I have to specify that I am not [yet] member in Linux Kernel Mailing
List.
Thank you,
Jean-Gabriel RICAN
This is the patch:
-----------------------------------------------------------------------
--- drivers/md/md.c.orig Wed Oct 3 22:27:48 2001
+++ drivers/md/md.c Thu Oct 11 10:56:45 2001
@@ -2388,9 +2388,18 @@
}
rdev = find_rdev(mddev, dev);
- if (rdev)
+ if (rdev && !rdev->faulty)
return -EBUSY;
+ if (rdev && rdev->faulty) {
+ err = hot_remove_disk(mddev, dev);
+ if (err == -EBUSY)
+ return -EBUSY;
+ if (err) {
+ MD_BUG();
+ return -EINVAL;
+ }
+ }
err = md_import_device (dev, 0);
if (err) {
printk(KERN_WARNING "md: error, md_import_device() returned %d\n", err);
--------------------------------------------------------------------------
On Thu, 11 Oct 2001 [email protected] wrote:
> Suppose you can hot-swap a hard disk in a system. Now if you have a
> degraded Software RAID device (for example a RAID-5 with one disk
> failed) and you replace the failed disk on-the-fly you cannot start
> reconstruction (with raidhotadd) of the Software RAID device with the
> replaced disk because it says it is BUSY.
this is possible already: you should first raidhotremove the failed drive,
then raidhotadd the new drive. It can be the 'same' drive if it's a
hot-swap disk, or it can be another, spare disk.
> + if (rdev && rdev->faulty) {
> + err = hot_remove_disk(mddev, dev);
what your patch does is a forced remove of any drive that is
raidhotadd-ed. This is less finegrained than the current solution, and
might make the method more volatile. (easier to mess up accidentally.) Is
there anything your patch allows that is not possible today, via
raidhotremove+raidhotadd?
Ingo
Ingo,
Yes you are right: raidhotadd does the job and I cannot believe that I
wasn't considering it myself. Probably I was so focused on the process of
adding a hot spare that I forgot to try this.
It looks that my patch isn't necessary required after all. The only
advantage that it offers is that it saves a raidhotremove call (and the test
to see if the drive is really faulty or still present in the RAID array -
because raidhotadd will fail in this case), but in rest it seems to be
rather equivalent.
Anyway, thank you for the solution and I hope that I didn't caused any
inconvenience.
Jean-Gabriel Rican
>
> > Suppose you can hot-swap a hard disk in a system. Now if you have a
> > degraded Software RAID device (for example a RAID-5 with one disk
> > failed) and you replace the failed disk on-the-fly you cannot start
> > reconstruction (with raidhotadd) of the Software RAID device with the
> > replaced disk because it says it is BUSY.
>
> this is possible already: you should first raidhotremove the failed drive,
> then raidhotadd the new drive. It can be the 'same' drive if it's a
> hot-swap disk, or it can be another, spare disk.
>
> > + if (rdev && rdev->faulty) {
> > + err = hot_remove_disk(mddev, dev);
>
> what your patch does is a forced remove of any drive that is
> raidhotadd-ed. This is less finegrained than the current solution, and
> might make the method more volatile. (easier to mess up accidentally.) Is
> there anything your patch allows that is not possible today, via
> raidhotremove+raidhotadd?
>
> Ingo
>