Hi Babu, On 2009/04/22 2:06 +0900, Moger, Babu wrote: > Hi Kiyoshi, > > Thanks for your comment. > > >> -----Original Message----- >> From: Kiyoshi Ueda [mailto:k-ueda@xxxxxxxxxxxxx] >> Sent: Monday, April 20, 2009 8:07 PM >> To: Moger, Babu >> Cc: 'dm-devel@xxxxxxxxxx'; linux-scsi@xxxxxxxxxxxxxxx; Chauhan, Vijay; >> 'sekharan@xxxxxxxxxx' >> Subject: Re: [PATCH] dm mpath: Try recover from I/O failure by re- >> initializing the PG if device is running on one path >> >> Hi Babu, >> >> On 2009/04/21 3:05 +0900, Moger, Babu wrote: >>> This patch introduces the mechanism to recover from I/O failures by >>> re-initializing the path if the device is running on only one path. >>> >>> Problem: Device mapper fails the path for every I/O error. It does not >>> care about the type of error. There are certain errors which can be >>> recovered by re-initializing the path again. I have seen this problem >>> during my testing on rdac device handler. I have observed I/O errors >>> when there is a change in Lun ownership. When Lun ownership changes >>> device will return back with check condition with >>> sense 0x05/0x94/0x01(SK/ASC/ASCQ -meaning Lun ownership changed). >>> Currently, device mapper fails the path for this error and eventually >>> this will lead to I/O error. We don't want to see I/O error for this >>> reason. >> >> Shouldn't we handle this type of device error inside device handler? > > The current error in question requires re-activation of the path. > We already have a code to handle this scenario in device handler. > But, the problem is the return status does not go to DM layer. > The return status gets lost in scsi layer. For DM layer all the errors > are -EIO. Any thoughts from your side. Oh, I missed the point and I thought that re-activating the path in your device handler was enough for the error. Currently, I have no idea to handle your case only in dm without seeing I/O error. By the way, who did change the ownership when the device was running with one path in your testing? I can't see why such case happened. Thanks, Kiyoshi Ueda -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
