Thread (8 messages) 8 messages, 2 authors, 2022-06-27

Re: [PATCH 1/2] mdadm: Fix array size mismatch after grow

From: Lukasz Florczak <hidden>
Date: 2022-06-27 13:18:45

On Tue, 21 Jun 2022 00:28:18 +0800, Coly Li [off-list ref] wrote:
quoted
2022年6月3日 22:30,Lukasz Florczak
[off-list ref] 写道:

On Mon, 30 May 2022 18:01:05 +0800, Coly Li [off-list ref] wrote:

Hi Coly,  
quoted
Hi Lukasz,

  
quoted
2022年4月7日 22:27,Lukasz Florczak
[off-list ref] 写道:

imsm_fix_size_mismatch() is invoked to fix the problem, but it
couldn't proceed due to migration check. This patch allows for
intended behavior.  

Could you please explain a bit more about why “it couldn’t proceed
due to migration”, and what is the “intended behavior”? It may help
me to understand your change and response faster.  
The intended behavior here is to fix the array size after grow that
is displayed in mdadm detail, since there can be a mismatch if the
raid was created in EFI [1]. That is the array size is not
consistent with the formula: 
Array_size * block_size = Num_stripes * Chunk_size *
Num_of_data_drives 

That fix couldn't happen as the metadata update part was efficiently
omitted with continue statement after the migration type condition
was met. 

About migration I didn't go that much into detail, but it was an
issue that dev->vol.migr_type was still in MIGR_GEN_MIGR state even
though imsm_fix_size_mismatch() was called after migration has been
finished, at least from the mdadm's point of view. That happens
because this value is changed later, afaik, by mdmon. The initial
idea here must've been not to change the array size during
migration, but that is not valid since its state is just not
updated yet.

[1]
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=895ffd992954069e4ea67efb8a85bb0fd72c3707
 
Copied, thanks for the hint.

BTW, now I do the imsm related test with IMSM_NO_PLATFORM=1 and
IMSM_DEVNAME_AS_SERIAL=1. To test situation as the above text
mentioned, do I have to find a real hardware with VROC supported?
Hi Coly,

Having a real hardware with VROC support would be the most convenient
solution here. However, you could do a quick hack to overcome this
situation. That would be commenting out the line:
array_size = round_size_to_mb(array_blocks, data_disks);
in init_super_imsm_volume(). Then creating RAID in OS should have the
same size mismatch issues as size per drive won't be aligned to 1MiB
(considering you create raid with size not aligned to 1MiB) - raid
size created in EFI only has to be multiple of sector size and chunk
size.
Hope this helps you.

Thanks,
Lukasz
Coly Li
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help