linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: NeilBrown <neilb@suse.de>
Cc: "Baldysiak, Pawel" <pawel.baldysiak@intel.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"Paszkiewicz, Artur" <artur.paszkiewicz@intel.com>
Subject: Re: IMSM - problem with reshape+systemd
Date: Thu, 15 May 2014 14:45:20 +1000	[thread overview]
Message-ID: <20140515144520.483db580@notabene.brown> (raw)
In-Reply-To: <20140424143138.222bd1f8@notabene.brown>

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

On Thu, 24 Apr 2014 14:31:38 +1000 NeilBrown <neilb@suse.de> wrote:

> On Fri, 18 Apr 2014 09:24:35 +0000 "Baldysiak, Pawel"
> <pawel.baldysiak@intel.com> wrote:
> 
> > Hi Neil/All.
> > We have discovered some problems with IMSM array reshape under OSs managed by systemd.
> > In case of reshape of arrays with IMSM metadata, mdadm manages the whole reshape process and it needs to be running in background.
> > If we reboot while reshaping, array will be assembled at startup
> > by udevworker by IMPORT{program}="mdadm -I /dev/sdX --export --offroot" part of udev rule array.
> > Mdadm will fork and continue to reshape an array from checkpoint.
> > However, systemd will treat udevworker as hanged process and it will be killed due to timeout with all its children (reshape will hang then).
> > I had planned to propose a patch for this problem, where additional unit file will be added
> > and udev will start systemd-service for mdadm -I command (see below),
> > but then we will lose information about exported variables - the ones that are used to trigger mdadm-last-resort service.
> > 
> > Do You have any idea how to solve this problem, and keep both functionalities?
> 
> Hi,
>  thanks for raising this issue.
> 
>  I think we need to address this using "mdadm --grow --continue".
> 
>  e.g. in used we run "mdadm -I --freeze-reshape --export" and arrange for
>  that to report some setting if a reshape is needed.
>  If it is needed, we set SYSTEMD_WANTS to some service which will run "mdadm
>  --grow --continue $device".
> 
>  Possibly we could get mdadm to run "systemctl start mdadm-reshape@$dev"
>  instead of forking, like it now does for running mdmon.
> 
>  I might have a poke at the code and see what falls out.
> 

Hi,
 I've just pushed some changes out to git://neil.brown.name/mdadm (and github)
which will hopefully address this problem.

I've added a new systemd unit, and mdadm will try to "systemctl start" it
rather than continuing on in the back ground.

It seems to work in at least one simple test case for me.  Can you check that
it works for you?

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2014-05-15  4:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <84A53BEA6EAC69439B7E311E9B17A76F078F1EE0@IRSMSX105.ger.corp.intel.com>
2014-04-24  4:31 ` IMSM - problem with reshape+systemd NeilBrown
2014-05-15  4:45   ` NeilBrown [this message]
2014-05-16 16:07     ` Baldysiak, Pawel
2014-05-20  7:02       ` NeilBrown

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=20140515144520.483db580@notabene.brown \
    --to=neilb@suse.de \
    --cc=artur.paszkiewicz@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=pawel.baldysiak@intel.com \
    /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).