[PATCH 1/1] UBUNTU: SAUCE: md: wait for possible pending deletes after stopping an array

Tim Gardner tim.gardner at canonical.com
Mon Mar 30 15:54:12 UTC 2009


Andy Whitcroft wrote:
> Bug: #334994
> 
> When stopping an array, we first wait for any pending deletes to occur
> and then remove all the disks from the array.  Unfortuanatly it is the
> removal of the disks from the array which triggers the the pending deletes.
> We should be waiting for them after they have been started.  Without this
> it is possible to stop and then attempt to restart an array before the
> deletes have occured leading to a start failure.  This is a common pattern
> if an array is found to be degraded on boot.  This leads to boot failures
> when failing back to degraded mode is acceptable.
> 
> Reorder the wait for completion till after the delete.
> 
> Signed-off-by: Andy Whitcroft <apw at canonical.com>
> ---
>  drivers/md/md.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index fb15676..3c85e5a 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -3916,11 +3916,11 @@ static int do_md_stop(mddev_t * mddev, int mode, int is_open)
>  				sysfs_remove_link(&mddev->kobj, nm);
>  			}
>  
> +		export_array(mddev);
> +
>  		/* make sure all md_delayed_delete calls have finished */
>  		flush_scheduled_work();
>  
> -		export_array(mddev);
> -
>  		mddev->array_sectors = 0;
>  		mddev->size = 0;
>  		mddev->raid_disks = 0;

ACK - this changes the semantics, but it looks right. I assume you've
consulted the upstream developers?

-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list