From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chandra Seetharaman Subject: Re: [BUG] dm-mpath and scsi persistent reservation Date: Wed, 22 Oct 2008 14:21:57 -0700 Message-ID: <1224710517.14830.852.camel@chandra-ubuntu> References: <20081021231910.0fdbeb75@plop> <1224629283.14830.838.camel@chandra-ubuntu> <20081022215402.214a4ef8@plop> Reply-To: sekharan@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:48792 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752357AbYJVVXJ (ORCPT ); Wed, 22 Oct 2008 17:23:09 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id m9MLMowH005927 for ; Wed, 22 Oct 2008 15:22:51 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9MLMwJL129720 for ; Wed, 22 Oct 2008 15:23:00 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9MLMSuS001205 for ; Wed, 22 Oct 2008 15:22:29 -0600 In-Reply-To: <20081022215402.214a4ef8@plop> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Christophe Varoqui Cc: jens.axboe@oracle.com, james.bottomley@hansenpartnership.com, agk@redhat.com, linux-scsi@vger.kernel.org, dm-devel@redhat.com 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html