From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: "NeilBrown" <neilb@suse.de>
Cc: "Song Liu" <song@kernel.org>,
"Linux regressions mailing list" <regressions@lists.linux.dev>,
Jes.Sorensen@gmail.com, "linux-raid" <linux-raid@vger.kernel.org>,
"LKML" <linux-kernel@vger.kernel.org>,
"Nikolay Kichukov" <hijacker@oldum.net>
Subject: Re: [regression] Bug 217074 - upgrading to kernel 6.1.12 from 5.15.x can no longer assemble software raid0
Date: Wed, 8 Mar 2023 09:55:42 +0100 [thread overview]
Message-ID: <20230308095542.00001bba@linux.intel.com> (raw)
In-Reply-To: <167822843274.8008.1142380266687607670@noble.neil.brown.name>
On Wed, 08 Mar 2023 09:33:52 +1100
"NeilBrown" <neilb@suse.de> wrote:
> On Tue, 07 Mar 2023, Mariusz Tkaczyk wrote:
> > On Mon, 06 Mar 2023 08:21:07 +1100
> > "NeilBrown" <neilb@suse.de> wrote:
> >
> > > On Sat, 04 Mar 2023, Song Liu wrote:
> > > > + Jes.
> > > >
> > > > It appeared to me that we can assemble the array if we have any of the
> > > > following:
> > > > 1. Enable CONFIG_BLOCK_LEGACY_AUTOLOAD;
> > > > 2. Have a valid /etc/mdadm.conf;
> > > > 3. Update mdadm to handle this case. (I tried some ugly hacks, which
> > > > worked but weren't clean).
> > > >
> > > > Since we eventually would like to get rid of
> > > > CONFIG_BLOCK_LEGACY_AUTOLOAD, I think we need mdadm to handle this
> > > > properly. But the logistics might be complicated, as
> > > > mdadm are shipped separately.
> > > >
> > > > Jes, what do you think about this? AFAICT, we need to update the logic
> > > > in mdopen.c:create_mddev().
> > >
> > > mdadm already handles this, but only if
> > > CREATE names=yes
> > > is present in /etc/mdadm.conf
> >
> > Hi,
> >
> > "CREATE names=yes" enforces creation of /dev/md_name arrays instead of
> > /dev/mdXXX. It is a large change for users, too aggressive IMO. It will
> > destroy many setups.
> >
> > To resolve it, we need is to use create_named_array() but respect old naming
> > convention. We already have find_free_devnm(), and we are able to keep
> > consistency because we can create 'mdXXX':
> >
> > /sys/module/md_mod/parameters # echo md125 > new_array
> >
> > /sys/module/md_mod/parameters # ll /sys/block/md125
> > lrwxrwxrwx 1 root root 0 Mar 7 10:54 /sys/block/md125 ->
> > ../devices/virtual/block/md125
> >
> > That will require adjustments in mdadm, but I think that we can keep
> > names the same way. I created the test for verification of base creation
> > flows, we can use it to avoid regression:
> > https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/tests/00createnames
> >
> > Thoughts?
>
> Yes, that is probably sensible.
>
> It would be nice to have a way to expose the "names=yes" functionality
> more obviously. I think people would generally prefer it (/proc/mdstat
> becomes more meaningful) but I agree that forcing it on people is the
> the best approach.
>
> Maybe a super-block flag that enables it for that array, and we start
> setting that flag when creating new arrays?
>
That is controversial. I don't feel that using metadata to resolve Linux issue
is as a good way. It will work for native for sure but for IMSM it is not such
simple.
I think that we can handle it by config file.
When we set "ARRAY /dev/mdXXX" then it is honored. I'm familiar with such
cases, that works. In such case link may or may not be generated so far I
remember but... nobody cares if array name is meaningful and we can fix that
too. It seems to not be a big deal.
I would like to propose doing same for 'names'.
If there is no config or name is set to "/dev/md/name" it should work as now.
So, if someone would need backward compatibility we can add flag to --detail
and --examine breifs forces that, let say --use-link-as-name. By default
"ARRAY /dev/md_name" entry will be generated.
My PoV is based on IMSM, there may be small differences between IMSM and native
but I think that it applies everywhere.
Thanks,
Mariusz
prev parent reply other threads:[~2023-03-08 8:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 16:06 [regression] Bug 217074 - upgrading to kernel 6.1.12 from 5.15.x can no longer assemble software raid0 Linux regression tracking (Thorsten Leemhuis)
2023-02-28 18:45 ` Song Liu
2023-03-01 7:20 ` Linux regression tracking (Thorsten Leemhuis)
2023-03-03 22:41 ` Song Liu
2023-03-05 21:21 ` NeilBrown
2023-03-06 17:48 ` Song Liu
2023-03-06 22:35 ` NeilBrown
2023-03-13 20:35 ` Song Liu
2023-03-07 8:52 ` Mariusz Tkaczyk
2023-03-07 19:44 ` Jes Sorensen
2023-03-07 22:33 ` NeilBrown
2023-03-08 8:55 ` Mariusz Tkaczyk [this message]
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=20230308095542.00001bba@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=Jes.Sorensen@gmail.com \
--cc=hijacker@oldum.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=regressions@lists.linux.dev \
--cc=song@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).