Hi,
we have to deal here with troublesome Infortrend devices. These units do
have 2 independent scsi channels, which are unfortunately not so
independent as they should be.
Now we have two different systems (lets say OSS-1 and OSS-2) connected to
each of the scsi-channels and both channels are serving different
partitions on the infortrend-raid units. So in principal whatever happens
on one channel should not effect the other channel.
Unfortunately, if one system (e.g. OSS-2) is rebooted while the other
(OSS-1) is doing i/o, it will cause trouble on the system doing i/o. These
problems are "task aborts", "reservation conflicts", etc.
I don't know how to solve the other problems yet, but i/o errors on
reservation conflicts can be easily prevented using this trivial patch:
--- linux-2.6.22.orig/drivers/scsi/scsi_error.c 2007-11-26
13:26:58.000000000 +0100
+++ linux-2.6.22/drivers/scsi/scsi_error.c 2007-11-26 13:27:26.000000000
+0100
@@ -1321,7 +1321,7 @@ int scsi_decide_disposition(struct scsi_
case RESERVATION_CONFLICT:
sdev_printk(KERN_INFO, scmd->device,
"reservation conflict\n");
- return SUCCESS; /* causes immediate i/o error */
+ return ADD_TO_MLQUEUE;
default:
return FAILED;
}
Now I would like to understand why a reservation conflict always does end in
an i/o error?
Almost the same applies to all the other problems we have with these
Infortrend boxes, in 99.999% of the time the boxes work fine, only
sometimes they suffer from hickup, which usually solves itself after a few
seconds. If we could just suspend i/o for that time, 99% of our problems
would be solved.
Cheers,
Bernd
-
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
