From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Laurence Perkins <lperkins@openeye.net>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: mdadm + Intel 12th gen.
Date: Wed, 25 Oct 2023 09:35:46 +0200 [thread overview]
Message-ID: <20231025093546.00000d91@linux.intel.com> (raw)
In-Reply-To: <MW2PR07MB40585189F6AC1CF7E8113790D2DFA@MW2PR07MB4058.namprd07.prod.outlook.com>
On Tue, 24 Oct 2023 16:54:26 +0000
Laurence Perkins <lperkins@openeye.net> wrote:
> Greetings!
>
> I have a Gigabyte motherboard:
> https://www.gigabyte.com/Motherboard/Q670M-D3H-DDR4-rev-10#kf
>
> With a 12th gen Intel processor:
> https://ark.intel.com/content/www/us/en/ark/products/134591/intel-core-i712700-processor-25m-cache-up-to-4-90-ghz.html
>
> Which I've set up to use dual NVMe drives as IMSM RAID via VMD.
>
> And I seem to have run into:
> https://bugzilla.redhat.com/show_bug.cgi?id=2053593
>
> As I understand it, mdadm is ignoring any IMSM RAID arrays that don't all
> come from the same SATA controller in order to avoid users accidentally
> creating such arrays with a selection of devices where they can't manage it
> via the BIOS menus. Up to now that was sensible.
>
> Unfortunately, VMD now lets non-SATA drives use features that used to be SATA
> only. So systems with NVMe drives can use all the BIOS features for them,
> including the RAID configuration and monitoring. But then mdadm sees that
> the drives aren't on a SATA controller and deliberately ignores them.
>
> For now I have hacked the workaround from that Redhat bug report into my
> initramfs (IMSM_NO_PLATFORM=1), but I expect this kind of configuration to
> get more common in the future. So perhaps it would be a good idea to make
> using them a little more intuitive. So since I don't manage to find any sign
> of the upstream bug report mentioned by the Redhat user actually having been
> filed I'm going to mention it now and ask if there are any plans for what to
> do with this in future versions.
>
> LMP
Hi Laurence,
Please provide what OS you are using. I think that all you need is in upstream:
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=75350d87c86001c47076e1f62478079bdc072223
but your mdadm has no support yet. Please consider updating mdadm or OS.
Please kindly note that what you are trying to use is a desktop RST family
software raid. Implementation in Linux is for VROC (formerly RSTe, enterprise
raid solution). Metadata format used by both solution is same, that is why
Linux is able to understand it but since both product has been separated many
years ago, there could be differences. Officially, we are not supporting such
configurations.
Thanks,
Mariusz
next prev parent reply other threads:[~2023-10-25 7:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 16:54 mdadm + Intel 12th gen Laurence Perkins
2023-10-25 7:35 ` Mariusz Tkaczyk [this message]
2023-10-25 18:17 ` Laurence Perkins
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=20231025093546.00000d91@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=lperkins@openeye.net \
/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