Commit "db91ff55bdf06736b" using curr_resync_completed instead of curr_resync when interrupted the resync operation

Commit "db91ff55bdf06736b" using curr_resync_completed instead of curr_resync when interrupted the resync operation

[majianpeng]

Hi Neil,
>commit db91ff55bdf06736b849afc1b1fce5763bbb8d5d
>    1/ If a resync is aborted we should record how far we got
>     (recovery_cp) the last request that we know has completed
>     (->curr_resync_completed) rather than the last request that was
>     submitted (->curr_resync).
If resync operation interrupted,it will call:
>	wait_event(mddev->recovery_wait, !atomic_read(&mddev->recovery_active));
So the curr_resync must be complete. Using curr_resync is safe.
--------------
majianpeng

Re: Commit "db91ff55bdf06736b" using curr_resync_completed instead of curr_resync when interrupted the resync operation

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Thu, 25 Oct 2012 14:16:02 +0800 majianpeng <majianpeng@gmail.com> wrote:

> Hi Neil,
> >commit db91ff55bdf06736b849afc1b1fce5763bbb8d5d
> >    1/ If a resync is aborted we should record how far we got
> >     (recovery_cp) the last request that we know has completed
> >     (->curr_resync_completed) rather than the last request that was
> >     submitted (->curr_resync).
> If resync operation interrupted,it will call:
> >	wait_event(mddev->recovery_wait, !atomic_read(&mddev->recovery_active));
> So the curr_resync must be complete. Using curr_resync is safe.
> --------------
> majianpeng

I must have had a reason for that patch.  Unfortunately the change log isn't
the best...

If the resync aborted cleanly with no errors (e.g. while stopping the array),
then I agree.
However if some read error was involved I'm not so sure.  I would have to
examine the code closely, which I don't feel up to at the moment (plenty of
other things to do).


NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]