On 19 May 2021, Leslie Rhorer spake thusly: > That's a little bit of an overstatement, depending on what you > mean by "reasonably confident". Swapped drives should not ordinarily > cause an issue, especially with RAID 4 or 5. The parity is, after all, > numerically unique. Admin changes to the array should be similarly > fully established provided the rebuild completed properly. I don't > think the parity algorythms have changed over time in mdadm, either. All sorts of creation-time things have changed over time: default chunk sizes, drive ordering (particularly but not only for RAID10), data offset, etc etc etc. The list is really rather long and the number of possible combinations astronomical. (Sure, it's less astronomical if you know what version of mdadm you made the array with in the first place, but hardly anyone who hasn't already been bitten tracks that, and if they do they probably recorded all the other relevant state too by preserving --examine output, so no guesswork is needed.) > Had they done so, mdadm would not be able to assemble arrays from > previous versions regardless of whether the superblock was intact. Naah. Most of this stuff is recorded *in* the superblock, so mdadm can assemble without difficulty or assistance: it doesn't do it by picking defaults from inside mdadm's source code! *Those* defaults only apply at array creation time. But when recreating an array over the top of a vanished one with the same parameters, you have to *remember* those parameters... -- NULL && (void)
