From: Larkin Lowrey <llowrey@nuclearwinter.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Stuck reshape
Date: Sun, 24 Nov 2013 19:44:10 -0600 [thread overview]
Message-ID: <5292AB6A.4010605@nuclearwinter.com> (raw)
In-Reply-To: <20131125104316.09a98169@notabene.brown>
On 11/24/2013 5:43 PM, NeilBrown wrote:
>> I initiated the re-shape with the following command (devices 4->5, level
>> 5->6, chunk 512->256):
>> mdadm --grow /dev/md1 --level=6 --raid-devices=6 --chunk=256
>
> So devices: 4 -> 6 ??
Correct, devices 4->6.
>
>>
>> The output was:
>> mdadm: level of /dev/md1 changed to raid6
>> mdadm: Need to backup 3072K of critical section..
>>
>> The status is:
>>
>> md1 : active raid6 sdo1[6] sdn1[5] sdd1[2] sdb1[4] sdc1[0] sda1[1]
>> 2929890816 blocks super 1.2 level 6, 512k chunk, algorithm 18
>> [6/5] [UUUU_U]
>> [>....................] reshape = 0.0% (512/976630272)
>> finish=56199369.9min speed=0K/sec
>> bitmap: 0/1 pages [0KB], 1048576KB chunk
>>
>> This process is chewing up a lot of CPU:
>> 2858 root 20 0 7936 3692 280 R 91.5 0.0 35:23.72 mdadm
>> 2856 root 20 0 0 0 0 R 24.4 0.0 14:05.14
>> md1_raid6
>> 2857 root 20 0 0 0 0 R 12.2 0.0 4:28.68
>> md1_reshape
>>
>> (that's 91.5% for mdadm, 24.4% for md1_raid6, and 12.2% for md1_reshape)
>>
>> All drives are on-line and functioning normally. I did forget to remove
>> the internal bitmap and I also forgot to use an external backup file.
>
> You don't need a backup file when increasing the number of data
drives, and
> recent kernels don't need you to remove the bitmap (and one those that
did,
> it would fail cleanly).
> So these aren't problems.
>
> Still, something is clearly wrong.
>
> It should be completely safe to reboot ... but given that I don't know
what
> the reshape is hanging here I cannot promise that the reshape won't hang
> again after a reboot.
>
> I'll try to reproduce this and see if I can understand what is happening.
> Meanwhile ... maybe try killing mdadm. That certainly won't hurt and may
> help.
>
> NeilBrown
>
Thank you for your reply. I managed to resolve this issue but hadn't
gotten around to replying with an update.
I noticed, via strace, that mdadm was reading from sysfs as fast as it
could and was trying to open sync_completed O_RDWR which it was unable
to do since it was read-only. Just for fun I changed sync_completed to
0644 and all mdadm did with that file was read from it. This was with
mdadm v3.2.6. This 'fix' did not change any aspect of the behavior other
than allowing mdadm to read the file w/o error.
I finally decided to 'echo max > /sys/block/md1/md/sync_max'. It had
been stuck at 1024. That unstuck the reshape and it completed
successfully. Being paranoid, I did a full compare of the most recent
backup and no (unexpected) differences were detected.
I did a 'echo t > /proc/sysrq-trigger' while things were stuck but it
overran the buffer rather badly.
--Larkin
prev parent reply other threads:[~2013-11-25 1:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-22 19:17 Stuck reshape Larkin Lowrey
2013-11-24 23:43 ` NeilBrown
2013-11-25 1:44 ` Larkin Lowrey [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5292AB6A.4010605@nuclearwinter.com \
--to=llowrey@nuclearwinter.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).