Re: mdadm freezes the system

[Roman Mamedov <roman@rm.pp.ru>]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

On Tue, 8 Jun 2010 14:59:13 +0600
Roman Mamedov <roman@rm.pp.ru> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]