RE: [dm-devel] [RESUBMIT][Patch] scsi_dh_rdac: retry IO for 06/3f/03 in rdac_check_sense fn

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 -----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: [dm-devel] [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
ÿô.nlj·Ÿ®‰­†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þÇ‹ø¡Ü}©ž²ÆzÚj:+v‰¨þø®w¥þŠàÞ¨è&¢)ß«a¶Úÿûz¹ÞúŽŠÝjÿŠwèf



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux