Mike Christie wrote:
Christophe Varoqui wrote:
I confirm a robust behaviour now with take 3.
Here is a take 4 that move to an appropriate "best effort mode", ie
always return success.
The point is, whenever DM start submitting io the an asleep controler,
precede with a START command. If it fails ... too bad, the consecutive
io will fail and DM will try another PG. Had to do that because take 3
interprets an error where the controler switch have correctly happened.
ok so is it if the controller is already failed over and we send the
START command, rq->errors had some value so I ended up failing the
operation, right? Let me send a patch that will dump the sense and
rq->errors info out so we can see if there is some nice ASC/ASCQ value
that will tell us this occured like with the LSI boxes.
oh wait, when I reread this I guess you are saying that I was always
gettting a rq->error value when I send a START_STOP and it succeeds?
