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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---

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);
 		}
 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux