On Sat, 27 Oct 2012 10:28:58 +0800 kernelmail <kedacomkernel@xxxxxxxxx> wrote: > In commit(db91ff55bdf06736b849afc1b1fce5763bbb8d5d),it said: > >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). > But when resync aborted, it execed > >wait_event(mddev->recovery_wait, !atomic_read(&mddev->recovery_active)); > After this, the ->curr_resync is the last completed request. > > Signed-off-by: Jianpeng Ma <majianpeng@xxxxxxxxx> > --- > drivers/md/md.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/md/md.c b/drivers/md/md.c > index 9ab768a..1d9940d 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -7558,8 +7558,7 @@ void md_do_sync(struct md_thread *thread) > printk(KERN_INFO > "md: checkpointing %s of %s.\n", > desc, mdname(mddev)); > - mddev->recovery_cp = > - mddev->curr_resync_completed; > + mddev->recovery_cp = mddev->curr_resync; > } > } else > mddev->recovery_cp = MaxSector; No. This reverts commit db91ff55bdf06736b849afc1b1fce5763bbb8d5d Maybe if we differentiated between an abort-due-to-error and an abort-due-to-request, then in the second card we could use ->curr_resync. NeilBrown
Attachment:
signature.asc
Description: PGP signature
