[dm-devel] Re: [BUG] dm-mpath and scsi persistent reservation

[Chandra Seetharaman]

On Wed, 2008-10-22 at 21:54 +0200, Christophe Varoqui wrote:
> It seems to me the device handler infrastructure proposes to translate
> scsi error codes from requests generated by the device handler itself. I

No, the handler doesn't generate the requests.

Device handler's check_sense() function is called from the
scsi_error.c:scsi_check_sense() function whenever a sense code is
returned from the device (on normal I/Os).

When in the sense function, the device handler can do any action (like
closing the other path(s)) and returning an appropriate error code (such
that dm doesn't retry the I/O on other paths).

> don't know how we can detect a reservation conflict from a device
> handler without submitting a dangerous write io.
> 
> I don't see how we could use a device handler to translate an scsi error
> code from a write io submitted to the multipath device map. Do you ?

That is what it actually does, it intercepts the sense code returned
from the device on normal I/Os.

> 
> Regards,
> cvaroqui
> > 
> > The SCSI Hardware handler is created for devices with special needs.
> > It is available in 2.6.27. One can be written for any device to
> > translate the scsi sense code to a different error code that the dm
> > understands. Is this something that coule help this situation ?
> > 
> > Have a look at drivers/scsi/device_handler directory.
> > 
> > Hope this helps,
> > 
> > chandra
> > On Tue, 2008-10-21 at 23:19 +0200, Christophe Varoqui wrote:
> > > Hi,
> > > 
> > > the dm-mpath multipathing driver enqueues write ios returned by
> > > the scsi layer with a "reservation conflict" error (on assymetric
> > > storage controllers, like Clariion, where queue_if_no_path is
> > > enabled).
> > > 
> > > This is wrong, and a potent data-corrupter : wio sent to a reserved
> > > scsi device should never be retried on this same device.
> > > 
> > > Can someone advise on a viable solution for this problem ? I
> > > understand the Device Mapper being a block remapper, it is not
> > > expected to receive scsi errors directly ... but maybe some kind of
> > > translation might be acceptable. Or is there hope in the
> > > request-based remapper ?
> > > 
> > > Jens, James, Alasdair, ... as maintainers of the involved
> > > subsystems, would you care to give some advise on the issue.
> > > 
> > > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html