On 03/19/12 12:08, NeilBrown wrote: > On Mon, 19 Mar 2012 11:59:55 +0100 Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> > wrote: > >> Hi, >> >> commit 2bb77736ae5dca0a189829fbb7379d43364a9dac >> Author: NeilBrown <neilb@xxxxxxx> >> Date: Wed Jul 27 11:00:36 2011 +1000 >> >> md/raid10: Make use of new recovery_disabled handling >> >> Caused a serious regression making it impossible to recover certain o2 >> layout raid10 arrays if they get enter a double degraded state. >> >> If I create an array like this: >> >> root@monkeybay ~]# mdadm --create /dev/md25 --raid-devices=4 --chunk=512 >> --level=raid10 --layout=o2 --assume-clean /dev/sda4 missing missing >> /dev/sdd4 > > o2 places data thus: > > A B C D > D A B C > > where columns are devices. > > You've created an array with no place to store B. > mdadm or really shouldn't let you do that. That is the bug. Here I was thinking it would rely on alien storage that would get swapped in magically when something was missing ;) Actually I thought raid10 here as operating more as two raid1's concatenated. >> mdadm: Defaulting to version 1.2 metadata >> mdadm: array /dev/md25 started. >> >> Then adding a spare like this: >> [root@monkeybay ~]# mdadm -a /dev/md25 /dev/sdb4 >> mdadm: added /dev/sdb4 >> >> The spare ends up being added into slot 4 rather than into the empty >> slot 1 and the array never rebuilds. > > How could it rebuild? There is nowhere to get B from. > > I'm surprised this every "worked"... but maybe I'm missing something. Well it seems to be more -ENOCLUE from my side here :) Should we do something in mdadm to prevent creating an array this way? Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
