On Thursday February 21, markb@ordern.com wrote: > > Hi, > > I have just started to use Linux RAID1 (stock 2.4.17 with Promise > TX200). Generally, my setup is working out OK but I have found a > problem when trying to remove a disk from an active array using "mdctl > --remove /dev/md9 /dev/hdg9". The remove fails with: > > Feb 21 10:39:10 rook kernel: md: trying to remove hdg9 from md9 ... > Feb 21 10:39:10 rook kernel: md: bug in file md.c, line 2334 ... > > Have I done something wrong, or is it a bug in md.c as the message > suggests? You have done something wrong. It is not really a bug in md.c, except that md.c is giving a misleading message, and that's a bug. You cannot remove active drives from an array. You have to "fail" them first: mdctl --fail /dev/md9 /dev/hdg9 mdctl --remove /dev/md9 /dev/hdg9 > > One other thing, I noticed during my experimentation that if I crash > the system then when it comes up again the mirrors are updated. Why > does it do this when neither drive in the mirror is guaranteed to be > more current than the other? I realise that making sure the mirrors > are consistent is a good thing but I find it worrying that it is so > keen to overwrite the mirrors with what it believes is the master copy. > > Maybe I don't understand the process here, perhaps someone could > explain briefly what happens in this situation. After a crash, the drives could be slightly different. For each block that is different, either could be considered an acceptable value. The filesystems checking/journal-replay should either correct or ignore all such blocks. But for RAID, it is important that all blocks e identical on both devices, so it arbitrarily chooses one to be the master and copies all data from there to the slave. Thus the filesystem (or whatever) can be certain that while it might see "wrong" or "old" data, it will at least see *consistant* data and so can act predictably. I hope that makes sense. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
