linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).