-----Original Message----- > From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi-owner@xxxxxxxxxxxxxxx] On Behalf Of James > Bottomley > Sent: Tuesday, October 26, 2010 3:22 PM > To: Mike Christie > Cc: device-mapper development; Chauhan, Vijay; James Bottomley; linux-scsi@xxxxxxxxxxxxxxx > Subject: Re: [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn > > On Tue, 2010-10-26 at 14:18 -0500, Mike Christie wrote: > > On 10/26/2010 08:53 AM, Chauhan, Vijay wrote: > > > Resubmitting this patch to get the attention. > > > > > > This patch adds retry for the IO returned with 06/3f/03((INQUIRY_DATA_CHANGED)) sense code in > rdac_check_sense(). IO returned with 06/3f/03 from controller are currently failed by scsi mid layer, > as a reason momentarily path failure is noticed by DM multipath. > > > > > > > Is it getting failed by accident? In scsi_io_completion we check for UAs > > and will retry if the removable bit is not set. That check is after > > scsi_end_request though (is the scsi_end_request call failing the IO). > > > > Did you guys also want REPORTED_LUNS_DATA_HAS_CHANGED to be retried too. > > I think scsi_dh_alua's REPORTED_LUNS_DATA_HAS_CHANGED maybe should be > > genericly retried, because it seems for both errors we will want to > > retry for all devices. > > So my primary worry about patches like this is that it eats AENs ... > this is fine because, as Mike says, we should just ignore them. > > However, the moment we start processing AENs (as another set of dm > people promise they have in process) we'll lose them from rdac arrays > and people will get unhappy. > > If the generic UA retry isn't working, let's fix it there rather than > these hacks that would be hard to spot and pull out when (if) we ever > get a generic AEN infrastructure. > > James Sometimes the default way to handle a UA may be not the correct one. One arrays implementation to respond to the UA could be different from another array. Example: A thin provisioning threshold exceed check condition. The device handler infrastructure can be a savior with such hacks.. -Shyam -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
