> 2022年6月3日 22:30，Lukasz Florczak <lukasz.florczak@xxxxxxxxxxxxxxx> 写道： > > On Mon, 30 May 2022 18:01:05 +0800, Coly Li <colyli@xxxxxxx> wrote: > > Hi Coly, >> Hi Lukasz, >> >> >>> 2022年4月7日 22:27，Lukasz Florczak >>> <lukasz.florczak@xxxxxxxxxxxxxxx> 写道： >>> >>> 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? Coly Li
