From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: "Sven Köhler" <sven.koehler@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: regression: drive was detected as raid member due to metadata on partition
Date: Tue, 7 May 2024 09:32:52 +0200 [thread overview]
Message-ID: <20240507093252.000032c2@linux.intel.com> (raw)
In-Reply-To: <93d95bbe-f804-4d12-bd0d-7d3cc82650b3@gmail.com>
On Tue, 9 Apr 2024 01:31:35 +0200
Sven Köhler <sven.koehler@gmail.com> wrote:
> I strongly believe that mdadm should ignore any metadata - regardless of
> the version - that is at a location owned by any of the partitions.
That would require mdadm to understand gpt parttable, not only clone it.
We have gpt support to clone the gpt metadata( see super-gpt.c).
It should save us from such issues so you have my ack if you want to do this.
But... GPT should have secondary header located at the end of the device, so
your metadata should be not at the end. Are you using gpt or mbr parttable?
Maybe missing secondary gpt header is the reason?
> 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.
No, it is not an option. In udev world, you should only operate on device you
are processing so we should avoid referencing the system.
BTW. To avoid this issue you can left few bytes empty at the end of disk, simply
make your last partition ended few bytes before end of the drive. With that
metadata will not be recognized directly on the drive. That is at least what I
expected but I'm not native experienced so please be aware of that.
> 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.
There are reasons why we introduced v1.2 located at the begging of device.
You can try to fix it but I think that you should just follow upstream and
choose 1.2 if you can.
As we are more and more with 1.2 that naturally we care less about 0.9,
especially of workarounds in other utilities. We cannot control
if legacy workarounds are still there (the root cause of this change may be
outside md/mdadm, you never know :)).
So the cases like that will always come. It is right to use 1.2 now to be
better supported if you don't have strong need to stay with 0.9.
Anyway, patches are always welcomed!
Thanks,
Mariusz
next prev parent reply other threads:[~2024-05-07 7:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 23:31 regression: drive was detected as raid member due to metadata on partition Sven Köhler
2024-04-10 1:56 ` 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 [this message]
2024-05-28 22:57 ` Sven Köhler
2024-06-12 14:36 ` Mariusz Tkaczyk
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=20240507093252.000032c2@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=sven.koehler@gmail.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).