On 2/8/19 5:07 AM, Mariusz Tkaczyk wrote:
> Commit d7a1fda2769b ("imsm: update metadata correctly while raid10 double
> degradation") resolves main Imsm double degradation problems but it
> omits one case. Now metadata hangs in the rebuilding state if the drive
> under rebuild is removed during recovery from double degradation.
>
> The root cause of this problem is comparing new map_state with current
> and if they both are degraded assuming that nothing new happens.
>
> Don't rely on map states, just check if device is failed. If the drive
> under rebuild fails then finish migration, in other cases update map
> state only (second fail means that destination map state can't be normal).
>
> To avoid problems with reassembling move end_migration (called after
> double degradation successful recovery) after check if recovery really
> finished, for details see (7ce057018 "imsm: fix: rebuild does not
> continue after reboot").
> Remove redundant code responsible for finishing rebuild process. Function
> end_migration do exactly the same. Set last_checkpoint to 0, to prepare
> it for the next rebuild.
>
> Signed-off-by: Mariusz Tkaczyk <mariusz.tkaczyk@xxxxxxxxx>
> ---
> super-intel.c | 26 +++++++++++---------------
> 1 file changed, 11 insertions(+), 15 deletions(-)
Applied!
Thanks,
Jes
