From: "Sven Köhler" <sven.koehler@gmail.com>
To: linux-raid@vger.kernel.org
Subject: regression: drive was detected as raid member due to metadata on partition
Date: Tue, 9 Apr 2024 01:31:35 +0200 [thread overview]
Message-ID: <93d95bbe-f804-4d12-bd0d-7d3cc82650b3@gmail.com> (raw)
Hi,
I was shocked to find that upon reboot, my Linux machine was detecting
/dev/sd[abcd] as members of a raid array. It would assign those members
to /dev/md4. It would not run the raid arrays /dev/mdX with members
/dev/sda[abcd]X for X=1,2,3,4 as it usually did for the past couple of
years.
My server was probably a unicorn in the sense that it used metadata
version 0.90. This version of software RAID metadata is stored at the
_end_ of a partition. In my case, /dev/sda4 would be the last partition
on drive /dev/sda. I confirmed with mdadm --examine that metadata with
the identical UUID would be found on both /dev/sda4 and /dev/sda.
Here's what I think went wrong: I believe either the kernel or mdadm
(likely the latter) was seeing the metadata at the end of /dev/sda and
ignored the fact that the location of the metadata was actually owned by
a partition (namely /dev/sda4). The same happened for /dev/sd[bcd] and
thus I ended up with /dev/md4 being started with members /dev/sda[abcd]
instead of members /dev/sda[abcd]4.
This behavior started recently. I saw in the logs that I had updated
mdadm but also the Linux kernel. mdadm and an appropriate mdadm.conf is
part of my initcpio. My mdadm.conf lists the arrays with their metadata
version and their UUID.
Starting a RAID array with members /dev/sda[abcd] somehow removed the
partitions of the drives. The partition table would still be present,
but the partitions would disappear from /dev. So /dev/sda[abcd]1-3 were
not visible anymore and thus /dev/md1-3 would not be started.
I strongly believe that mdadm should ignore any metadata - regardless of
the version - that is at a location owned by any of the partitions.
While I'm not 100% sure how to implement that, the following might also
work: first scan the partitions for metadata, then ignore if the parent
device has metadata with a UUID previously found.
I did the right thing and converted my RAID arrays to metadata 1.2, but
I'd like to save other from the adrenaline shock.
Kind Regards,
Sven
next reply other threads:[~2024-04-08 23:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 23:31 Sven Köhler [this message]
2024-04-10 1:56 ` regression: drive was detected as raid member due to metadata on partition Li Nan
2024-04-10 20:59 ` Sven Köhler
2024-04-11 2:25 ` Li Nan
2024-04-13 21:37 ` Sven Köhler
2024-04-18 7:31 ` Li Nan
2024-04-18 22:07 ` Sven Köhler
2024-04-18 22:11 ` Sven Köhler
2024-05-07 7:32 ` Mariusz Tkaczyk
2024-05-28 22:57 ` Sven Köhler
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=93d95bbe-f804-4d12-bd0d-7d3cc82650b3@gmail.com \
--to=sven.koehler@gmail.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).