AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-25 06:50:52 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity

raid5-cache: don't delay stripe captured in log

Browse Source 
There is a case a stripe gets delayed forever.
1. a stripe finishes construction
2. a new bio hits the stripe
3. handle_stripe runs for the stripe. The stripe gets DELAYED bit set
since construction can't run for new bio (the stripe is locked since
step 1)

Without log, handle_stripe will call ops_run_io. After IO finishes, the
stripe gets unlocked and the stripe will restart and run construction
for the new bio. With log, ops_run_io need to run two times. If the
DELAYED bit set, the stripe can't enter into the handle_list, so the
second ops_run_io doesn't run, which leaves the stripe stalled.

Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: NeilBrown <neilb@suse.com>
This commit is contained in:
Shaohua Li 2015-09-04 14:14:16 -07:00 committed by NeilBrown
parent 85f2f9a4f4
commit 253f9fd41a
1 changed files with 5 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
drivers/md/raid5-cache.c
View File

@ -479,6 +479,11 @@ int r5l_write_stripe(struct r5l_log *log, struct stripe_head *sh)
return -EINVAL; return -EINVAL;
set_bit(STRIPE_LOG_TRAPPED, &sh->state); set_bit(STRIPE_LOG_TRAPPED, &sh->state);
/*
* The stripe must enter state machine again to finish the write, so
* don't delay.
*/
clear_bit(STRIPE_DELAYED, &sh->state);
atomic_inc(&sh->count); atomic_inc(&sh->count);
mutex_lock(&log->io_mutex); mutex_lock(&log->io_mutex);