Hi, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know. [...] > commit ed209584c38fb74b7eecc03e5b1bfe674e591bd8 upstream. > > Commit 7bfec5f35c68121e7b18 > > md/raid5: If there is a spare and a want_replacement device, start > replacement. > > cause md_check_recovery to call ->add_disk much more often. > Instead of only when the array is degraded, it is now called whenever > md_check_recovery finds anything useful to do, which includes > updating the metadata for clean<->dirty transition. > This causes unnecessary work, and causes info messages from ->add_disk > to be reported much too often. Does 3.2.y need this? Commit 7bfec5f35c68121e7b18 (aka v3.3-rc3~3^2~22) does not seem to be part of the 3.2-stable tree. Jonathan > So refine md_check_recovery to only do any actual recovery checking > (including ->add_disk) if MD_RECOVERY_NEEDED is set. > > This fix is suitable for 3.3.y: > > Reported-by: Jan Ceuleers <[email protected]> > Signed-off-by: NeilBrown <[email protected]> > Signed-off-by: Ben Hutchings <[email protected]> > --- > drivers/md/md.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/md/md.c b/drivers/md/md.c > index b572e1e..8beb19c 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -7560,14 +7560,14 @@ void md_check_recovery(struct mddev *mddev) > * any transients in the value of "sync_action". > */ > set_bit(MD_RECOVERY_RUNNING, &mddev->recovery); > - clear_bit(MD_RECOVERY_NEEDED, &mddev->recovery); > /* Clear some bits that don't mean anything, but > * might be left set > */ > clear_bit(MD_RECOVERY_INTR, &mddev->recovery); > clear_bit(MD_RECOVERY_DONE, &mddev->recovery); > > - if (test_bit(MD_RECOVERY_FROZEN, &mddev->recovery)) > + if (!test_and_clear_bit(MD_RECOVERY_NEEDED, &mddev->recovery) || > + test_bit(MD_RECOVERY_FROZEN, &mddev->recovery)) > goto unlock; > /* no recovery is running. > * remove any failed drives, then -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
