[dm-devel] RE: [RFC PATCH 4/4] convert scsi to blkerr error values

["goggin, edward" <egoggin emc com>]

> -----Original Message-----
> From: Mike Christie [mailto:michaelc cs wisc edu] 
> Sent: Friday, September 16, 2005 4:54 PM
> To: goggin, edward
> Cc: axboe suse de; linux-scsi vger kernel org; dm-devel redhat com
> Subject: Re: [RFC PATCH 4/4] convert scsi to blkerr error values
> 
> Mike Christie wrote:
> > goggin, edward wrote:
> > 
> >> Mike,
> >>
> >> I don't think it is reasonably possible to anticipate
> >> all possible parsing requirements for the asc and ascq
> >> portions of SCSI sense information across all device
> >> models.  I'm in favor of having a "small" framework in
> >> SCSI where a SCSI sense interpreter module (per
> >> vendor & model possibly) could be registered
> >> dynamically, by dm-emc.c for instance.
> > 
> > 
> > Yeah I agree, I mentioned this before in some other mails. 
> I think a 
> > module versus some table that userspace could write to were 
> discussed.
> > 
> > The BLKERR values were meant to be able to tell upper layer 
> code whether 
> > a transport or device or driver error occured and whether the lower 
> > level thought it was retryable. But then I thought I could 
> also wedge in 
> > the handling of the vendor specifcs by adding a vendor 
> specific SCSI 
> > module that would map the their specific value to a 
> BLKERR_* one. And as 
> > I said offlist it is not working perfectly becuase we are 
> losing some 
> > information in the translations.
> > 
> 
> Oh yeah so the problem I am having is emc boxes may return "LUN Not 
> Ready - Manual Intervention Required". When dm-emc.c sees 
> this error it 
> wants to bypass a group of paths and retry the IO but under ceratin 
> conditions not fail those paths. So I am not sure what to return for 
> this error. I thought if I redo my BLKERR so they describe 
> the error like
> 
> BLKERR_DEV_NOT_READY
> BLKERR_MANUAL_INTERVENTION_REQ
> BLKERR_NOT_CONN
> 
> ... and set them up as a bitmap like suggested by JamesB. I 
> could return
> BLKERR_MANUAL_INTERVENTION_REQ from a scsi module then have dm-emc.c 
> evaluate that value to a dm-mpaths return value of "MP_BYPASS_PG | 
> MP_RETRY_IO" which means bypass the priority group (group of 
> paths) and 
> retry the IO.
> 
> But as more vendors use dm and they cannot use existing 
> BLKERR values I 
> have to add more and more.

I was hoping we could avoid the need to do this by having the framework
described in my email -- the idea for which I heard about from you in
the first place :))

> some block layer code may return BLKERR_MANUAL_INTERVENTION_REQ for 
> something not related to the reasons EMC's HW was returning "LUN Not 
> Ready - Manual Intervention Required" and we end up with 
> getting things 
> wrong.

Good point, I hadn't thought of that case.

>