On Sat, Nov 24, 2007 at 07:44:13PM +0200, James Bottomley wrote: > Probing intermittent failures in Domain Validation, even with the fixes > applied leads me to the conclusion that there are further problems with > this commit: > > commit fc5eb4facedbd6d7117905e775cee1975f894e79 > Author: Hannes Reinecke <hare@xxxxxxx> > Date: Tue Nov 6 09:23:40 2007 +0100 > > [SCSI] Do not requeue requests if REQ_FAILFAST is set > > The essence of the problems is that you're causing REQ_FAILFAST to > terminate commands with error on requeuing conditions, some of which are > relatively common on most SCSI devices. While this may be the correct > behaviour for multi-path, it's certainly wrong for the previously > understood meaning of REQ_FAILFAST, which was don't retry on error, > which is why domain validation and other applications use it to control > error handling, but don't expect to get failures for a simple requeue > are now spitting errors. > > I honestly can't see that, even for the multi-path case, returning an > error when we're over queue depth is the correct thing to do (it may not > matter to something like a symmetrix, but an array that has a non-zero > cost associated with a path change, like a CPQ HSV or the AVT > controllers, will show fairly large slow downs if you do this). Even if > this is the desired behaviour (and I think that's a policy issue), > DID_NO_CONNECT is almost certainly the wrong error to be sending back. > > This patch fixes up domain validation to work again correctly, however, > I really think it's just a bandaid. Do you want to rethink the above > commit? > Given the amounted error, yes, I'll have to. But we still face the initial problem that requeued requests will be stuck in the queue forever (ie until the timeout catches it), causing failover to be painfully slow. Anyway, I'll think it over. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�rnberg GF: Markus Rex, HRB 16746 (AG N�rnberg) - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
