On Tue, 8 Jun 2010 14:59:13 +0600 Roman Mamedov <roman@xxxxxxxx> wrote: > Today, I have decided to convert a three-member RAID5 into a four-member > RAID6. mdadm segfaulted(!) right after the --grow command, and dmesg had > an error about md being unable to overwrite the /sys/.....stripe_cache_size > file. (As I understand, this is already fixed in the latest kernel). > > The array then started rebuilding as 4-member RAID6 seemingly fine, but > shortly after, the system locked up in the same manner as described above. Interestingly though, when I attempted that reshape in 2.6.34 (complete with the described segfault), the array _instantly_ became a 4-disk RAID6 with a rebuilding spare, and the process was running at about 50 MB/sec. And I was able to then remove that spare and shrink the array back to --level=5 and --raid-devices=3, instantly too. But when I rebooted to 2.6.35-rc2, the same --grow command I used initially (--level=6 --raid-devices=4) while did not produce a segfault, failed, asking for the "backup file" to be specified. And after I added the --backup-file switch, it started a slow "Reshape" process, going at about 6 MBytes per second. (And this too, caused a lockup in a way which I described earlier.) Apparently, there is no way to abort this process now, so I paused it using echo idle > /sys/.....sync_action, and copying data away from the array, to recreate it from scratch. So why the same RAID5 to RAID6 conversion started so differently in these two cases? And is it even possible to reshape RAID5 to RAID6 while simultaneously adding a disk, without overwriting all the other disks' contents (it surely looked like this is what was happening in the first case)? -- With respect, Roman
Attachment:
signature.asc
Description: PGP signature
