On 19 Jul 2022, Guoqing Jiang spake thusly:
> On 7/18/22 8:20 PM, Nix wrote:
>> So I have a pair of RAID-6 mdraid arrays on this machine (one of which
>> has a bcache layered on top of it, with an LVM VG stretched across
>> both). Kernel 5.16 + mdadm 4.0 (I know, it's old) works fine, but I just
>> rebooted into 5.18.12 and it failed to assemble. mdadm didn't display
>> anything useful: an mdadm --assemble --scan --auto=md --freeze-reshape
>> simply didn't find anything to assemble, and after that nothing else was
>> going to work. But rebooting into 5.16 worked fine, so everything was
>> (thank goodness) actually still there.
>>
>> Alas I can't say what the state of the blockdevs was (other than that
>> they all seemed to be in /dev, and I'm using DEVICE partitions so they
>> should all have been spotte
>
> I suppose the array was built on top of partitions, then my wild guess is
> the problem is caused by the change in block layer (1ebe2e5f9d68?),
> maybe we need something similar in loop driver per b9684a71.
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index c7ecb0bffda0..e5f2e55cb86a 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -5700,6 +5700,7 @@ static int md_alloc(dev_t dev, char *name)
> mddev->queue = disk->queue;
> blk_set_stacking_limits(&mddev->queue->limits);
> blk_queue_write_cache(mddev->queue, true, true);
> + set_bit(GD_SUPPRESS_PART_SCAN, &disk->state);
> disk->events |= DISK_EVENT_MEDIA_CHANGE;
> mddev->gendisk = disk;
> error = add_disk(disk);
I'll give it a try. But... the arrays, fully assembled:
Personalities : [raid0] [raid6] [raid5] [raid4]
md125 : active raid6 sda3[0] sdf3[5] sdd3[4] sdc3[2] sdb3[1]
15391689216 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]
md126 : active raid6 sda4[0] sdf4[5] sdd4[4] sdc4[2] sdb4[1]
7260020736 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU]
bitmap: 0/2 pages [0KB], 1048576KB chunk
md127 : active raid0 sda2[0] sdf2[5] sdd2[3] sdc2[2] sdb2[1]
1310064640 blocks super 1.2 512k chunks
unused devices: <none>
so they are on top of partitions. I'm not sure suppressing a partition
scan will help... but maybe I misunderstand.
--
NULL && (void)
