From: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
To: Hannes Reinecke <hare@suse.de>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: [PATCH 2/2] Manage: Inform udev about device removal when stopping
Date: Tue, 16 Feb 2016 17:58:00 +0100 [thread overview]
Message-ID: <56C35518.6080709@profitbricks.com> (raw)
In-Reply-To: <56C3447A.3050504@suse.de>
On 16.02.2016 16:47, Hannes Reinecke wrote:
> Hi Sebastian,
>
> while it's true in general that a 'change' event should not be sent
> when a device is being removed or deleted, sending a 'remove' event
> from userspace is most definitely wrong, too.
> 'remove' events should be generated from the kernel whenever a
> device disappears from sysfs; it should never be generated from
> userspace (as the device will still be present in sysfs).
Hi Hannes,
thanks for your comment! Only few people actually stop md devices
without rebooting. As a hotfix for running systems it is definitely the
best solution for us at PB to do it in mdadm. Mdadm knows in this
situation that stopping worked.
But I'm also fine with dropping the support for kernels prior to 2.6.28
and the event sending in mdadm completely for the mainline. Sending the
kernel patch to linux-stable is kind of useless if mdadm still sends the
change event.
So your vote seems to be dropping the udev event sending in mdadm and
going for the kernel change.
I'll wait for other comments or votes for the preferred solution.
Cheers,
Sebastian
next prev parent reply other threads:[~2016-02-16 16:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 15:47 [PATCH 2/2] Manage: Inform udev about device removal when stopping Hannes Reinecke
2016-02-16 16:58 ` Sebastian Parschauer [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-02-16 14:44 [PATCH 0/2] md/mdadm: " Sebastian Parschauer
2016-02-16 14:44 ` [PATCH 2/2] Manage: " Sebastian Parschauer
2016-02-16 17:41 ` Jes Sorensen
2016-02-16 18:03 ` Sebastian Parschauer
2016-02-16 18:40 ` Hannes Reinecke
2016-02-16 18:52 ` Jes Sorensen
2016-02-16 20:46 ` NeilBrown
2016-02-16 22:02 ` Jes Sorensen
2016-02-17 10:31 ` Sebastian Parschauer
2016-02-17 7:03 ` Hannes Reinecke
2016-02-17 13:06 ` Jes Sorensen
2016-02-17 13:16 ` Sebastian Parschauer
2016-02-17 17:33 ` Jes Sorensen
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=56C35518.6080709@profitbricks.com \
--to=sebastian.riemer@profitbricks.com \
--cc=hare@suse.de \
--cc=linux-raid@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).