On Wed, 7 Sep 2005, James Bottomley wrote:
> I agree (about the deadlocks). However, as things stand RECOVERY is a
> state in the model and the model can only be in a single state. If you
> permit the transition, and recovery is going on in parallel with
> removal, they'll race to set the final state (removal wants DEL and the
> eh thread will set it to RUNNING).
>
> Either we go back to having an in_recovery flag (i.e. lift recovery out
> of the state model) or we make the model more complex to cope with this.
> Since really the only thing we test is in_recovery, we could do a more
> complex model; something like:
>
> created
> |
> v <---------
> running ---------> recovery
> | |
> v <---------- v
> cancel ----------> recover/cancel
> | |
> v -----------> v
> del <------------ recover/del
>
> I also think I'd like not to go from del -> recover/del, but unless del
> actually means that all devices have completed their I/O for deletion
> that can't be avoided.
I don't understand your reasoning. With your new system, you end up with
two threads doing this:
Removal thread Error handler thread
------------------------- ---------------------------
Go from RUNNING to RECOVERY
Try to go to CANCEL, fail
Go to CANCEL_RECOVERY
race: Go to DEL_RECOVERY Try to go to RUNNING, fail
Whereas the old system has the two threads doing this:
Removal thread Error handler thread
------------------------- ---------------------------
Go from RUNNING to RECOVERY
Go to CANCEL
race: Go to DEL Try to go to RUNNING, fail
At least, that's how it would work if you allow the RECOVERY -> CANCEL
transition. Either way you end up in the correct state. So what's wrong
with the old (current) system?
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
