Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Xiao Ni <xni@redhat.com>
To: jes@trained-monkey.org
Cc: pmenzel@molgen.mpg.de, ncroxon@redhat.com, linux-raid@vger.kernel.org
Subject: [PATCH v2 1/1] mdadm/udev: Don't handle change event on raw devices
Date: Thu,  5 Jan 2023 00:29:20 +0800	[thread overview]
Message-ID: <20230104162920.18172-1-xni@redhat.com> (raw)

The raw devices are ready when add event happpens and the raid
can be assembled. So there is no need to handle change events.
And it can cause some inconvenient problems.

For example, the OS is installed on md0(/root) and md1(/home).
md0 and md1 are created on partitions. When it wants to re-install
OS, anaconda can't clear the storage configure. It deletes one
partition and does some jobs. The change event happens. Now
the raid device is assembled again. It can't delete the other
partitions.

So in this patch, we don't handle change event on raw devices
anymore.

Signed-off-by: Xiao Ni <xni@redhat.com>
---
 udev-md-raid-assembly.rules | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/udev-md-raid-assembly.rules b/udev-md-raid-assembly.rules
index 39b4344b8592..d4a7f0a5a049 100644
--- a/udev-md-raid-assembly.rules
+++ b/udev-md-raid-assembly.rules
@@ -11,6 +11,11 @@ SUBSYSTEM!="block", GOTO="md_inc_end"
 ENV{SYSTEMD_READY}=="0", GOTO="md_inc_end"
 
 # handle potential components of arrays (the ones supported by md)
+# For member devices which are md/dm devices, we don't need to
+# handle add event. Because md/dm devices need to do some init jobs.
+# Then the change event happens.
+# When adding md/dm devices, ID_FS_TYPE can only be linux_raid_member
+# after change event happens.
 ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc"
 
 # "noiswmd" on kernel command line stops mdadm from handling
@@ -28,6 +33,9 @@ GOTO="md_inc_end"
 
 LABEL="md_inc"
 
+# Bare disks are ready when add event happens, the raid can be assembled.
+ACTION=="change", KERNEL!="dm-*|md*", GOTO="md_inc_end"
+
 # remember you can limit what gets auto/incrementally assembled by
 # mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
 ACTION!="remove", IMPORT{program}="BINDIR/mdadm --incremental --export $devnode --offroot $env{DEVLINKS}"
-- 
2.32.0 (Apple Git-132)


             reply	other threads:[~2023-01-04 16:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04 16:29 Xiao Ni [this message]
2023-01-04 23:38 ` [PATCH v2 1/1] mdadm/udev: Don't handle change event on raw devices 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=20230104162920.18172-1-xni@redhat.com \
    --to=xni@redhat.com \
    --cc=jes@trained-monkey.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=ncroxon@redhat.com \
    --cc=pmenzel@molgen.mpg.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