A correction: I used: mdadm --assemble /dev/md11 --scan to assemble md11. > 6. --re-add /dev/nbd0 > > At step 6, the array decided to go into recovery: > > Dec 19 14:32:26 turnip kernel: md: bind<nbd0> > Dec 19 14:32:26 turnip kernel: RAID1 conf printout: > Dec 19 14:32:26 turnip kernel: --- wd:1 rd:2 > Dec 19 14:32:26 turnip kernel: disk 0, wo:1, o:1, dev:nbd0 > Dec 19 14:32:26 turnip kernel: disk 1, wo:0, o:1, dev:sda > Dec 19 14:32:26 turnip kernel: md: recovery of RAID array md11 > > and has some time to go ... > > [=>...................] recovery = 7.7% (6031360/78123988) > finish=234.6min speed=5120K/sec (I bumped the recovery speed up to it's maximum, FYI.) Going off of the timestamps below, it took about 35 minutes to recover. That's way faster than the more than 2 hours necessary for a full sync. Therefore, I must assume that the bitmap is at least partially working. Dec 19 15:06:41 turnip kernel: md: md11: recovery done. Dec 19 15:06:41 turnip kernel: RAID1 conf printout: Dec 19 15:06:41 turnip kernel: --- wd:2 rd:2 Dec 19 15:06:41 turnip kernel: disk 0, wo:0, o:1, dev:nbd0 Dec 19 15:06:41 turnip kernel: disk 1, wo:0, o:1, dev:sda I'm going to re-do this experiment and grab an --examine-bitmap after a minute or so into the rebuild to see what happens. I am tentatively saying that the commit you suggested may be the root cause of some of the "unnecessary full-sync" issues I've had. -- Jon -- 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
