On Saturday July 13, martin.bene@icomedias.com wrote: > Hi Neil, Jason > > > Get mdadm > > http://www.cse.unsw.edu.au/~neilb/source/mdadm/ > > > > and use > > mdadm --assemble --force /dev/md0 /dev/hd...... > > shouldn't /dev/hda be left out of the list here? since it looks like hda > really is out out date I think you'd get best results by using only the most > up-to-date disks. hda certainly could be left out, but the point of "mdadm -Af" is that it tried to do the "best" thing. You don't *need* to figure out in too much detail what has gone wrong. It will pick the best available drives and use them. > > Also, when using the mkraid -force method that had to be used before mdadm, I > always recommended leaving out all spare disks and one of the data disks, > forcing the array to be (re)created in degraded mode. that way, write > operations to the disks are kept to a minimum and it's possible to retry if > you made an error (wrong disk left out etc). > > would it make sense to treat mdadm similarely, i.e only provide enough > devices to assemble a degraded array and hotadd the final device after the > array checks out ok? I don't like the idea of background parity rebuild > kicking in before I've had a chance to check things out. In general I would agree with that. I would actually like to be able to start an array in "read-only" mode and have no rebuild/resync happen until it got switched to write only. This may well happen in 2.6. 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
