From: NeilBrown <nfbrown@novell.com>
To: "Phil Turmel" <philip@turmel.org>,
"Björn Augustsson" <oggust@gmail.com>,
linux-raid@vger.kernel.org
Subject: Re: Reshape stuck immediately, backup file all nulls
Date: Thu, 11 Feb 2016 15:22:15 +1100 [thread overview]
Message-ID: <8760xvx4eg.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <56ACEE63.6070108@turmel.org>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
On Sun, Jan 31 2016, Phil Turmel wrote:
> Hi Björn,
>
> On 01/30/2016 07:21 AM, Björn Augustsson wrote:
>
>> The question is, what kind of state am in now?
>
> The kernel is waiting for mdmon (mdadm as a background task) to step
> through the stripes. mdmon died and the kernel will wait forever.
Close, not quite.
'mdmon' is a background task that mdadm *only* uses for externally
managed metadata: IMSM and DDF.
For a reshape like this mdadm needs a background "mdadm" task. It used
to just fork, but in these enlightened days it asks systemd to run that
task.
As has already been observed, that failed due to selinux not
understanding.
So it was an 'mdadm' which exited, rather than an mdmon which died...
Maybe you already worked that out.
The days of backup files should be numbered. New kernels and new mdadm
adjust the data-offset so no back is needed. In that case, no
background mdadm is needed either.
NeilBrown
>
>> And how should I recover?
>> Will just adding a policy to allow access to that file, and then
>> mdadm --grow --continue /dev/md127
>> fix it?
>
> Probably. Others have fixed this by disabling selinux for the reshape.
> Don't forget to specify --backup-file again on the command line. (I
> don't use selinux myself, so I can't be more specific.)
>
> In the future, consider not using a backup file at all -- mdadm
> generally leaves enough dead space on devices to avoid the need.
>
>> Is the broken backup file going to be a problem?
>
> Shouldn't be. Report back if it is.
>
> Phil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
next prev parent reply other threads:[~2016-02-11 4:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-30 12:21 Reshape stuck immediately, backup file all nulls Björn Augustsson
2016-01-30 17:09 ` Phil Turmel
2016-01-31 14:59 ` Björn Augustsson
2016-02-01 1:02 ` George Rapp
2016-02-01 18:45 ` Björn Augustsson
2016-02-11 4:22 ` NeilBrown [this message]
2016-01-30 18:13 ` Mikael Abrahamsson
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=8760xvx4eg.fsf@notabene.neil.brown.name \
--to=nfbrown@novell.com \
--cc=linux-raid@vger.kernel.org \
--cc=oggust@gmail.com \
--cc=philip@turmel.org \
/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