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

DISCUSSION majianpeng 2 participants 2 messages Oct 25, 2012 – Oct 28, 2012 MD RAID

lore

Share & tools

lore

majianpeng

author

2012-10-25 06:16 UTC #0 lore raw

Hi Neil,

Quoted 5 lines

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:

Quoted 1 line

	wait_event(mddev->recovery_wait, !atomic_read(&mddev->recovery_active));

So the curr_resync must be complete. Using curr_resync is safe.
--------------
majianpeng

NeilBrown

2012-10-28 22:47 UTC #1 lore raw

Quoted 11 lines · On Thu, 25 Oct 2012 14:16:02 +0800 majianpeng <[email protected]> wrote:

Hi Neil,
Quoted 5 lines
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:
Quoted 1 line
	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