Re: [PATCH] xfs_repair: kick processing thread if ra_count is at limit

[Dave Chinner <david@fromorbit.com>]

On Wed, Oct 24, 2018 at 06:11:46PM -0500, Eric Sandeen wrote:
> Zorro hit an xfs_repair hang on a 500T filesystem where
> all the prefetch threads were sleeping and nothing progressed.
> 
> The problem is that if every buffer we tried to read ahead in
> phase6 was already up to date, pf_start_io_workers has no effect;
> there is no io to do, and the sem_wait in pf_queuing_worker waits
> forever.
> 
> Kick the processing thread to avoid this situation.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201173
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
> 
> My brains started leaking out debugging this, but it works,
> and it seems harmless. :D  Happy to have review from anyone who groks
> the prefetch thread management better than I do...
> 
> diff --git a/repair/prefetch.c b/repair/prefetch.c
> index 9571b24..1de0e2f 100644
> --- a/repair/prefetch.c
> +++ b/repair/prefetch.c
> @@ -768,8 +768,12 @@ pf_queuing_worker(
>  			 * might get stuck on a buffer that has been locked
>  			 * and added to the I/O queue but is waiting for
>  			 * the thread to be woken.
> +			 * Start processing as well, in case everything so
> +			 * far was already prefetched and the queue is empty.
>  			 */
> +			
>  			pf_start_io_workers(args);
> +			pf_start_processing(args);
>  			sem_wait(&args->ra_count);
>  		}

Looks reasonable. We've had other bugs like this in the prefetch
code, so I'm not surprised there are still some lurking.

Reviewed-by: Dave Chinner <dchinner@redhat.com>

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com