From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Varoqui Subject: Re: [BUG] dm-mpath and scsi persistent reservation Date: Wed, 22 Oct 2008 21:54:02 +0200 Message-ID: <20081022215402.214a4ef8@plop> References: <20081021231910.0fdbeb75@plop> <1224629283.14830.838.camel@chandra-ubuntu> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1224629283.14830.838.camel@chandra-ubuntu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: sekharan@us.ibm.com Cc: james.bottomley@hansenpartnership.com, dm-devel@redhat.com, linux-scsi@vger.kernel.org, agk@redhat.com, jens.axboe@oracle.com List-Id: linux-scsi@vger.kernel.org It seems to me the device handler infrastructure proposes to translate scsi error codes from requests generated by the device handler itself. I 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 ? 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. > > > >