From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [dm-devel] Re: [BUG] dm-mpath and scsi persistent reservation Date: Wed, 22 Oct 2008 14:30:16 -0600 Message-ID: <1224707416.6851.33.camel@localhost.localdomain> References: <20081021231910.0fdbeb75@plop> <1224629283.14830.838.camel@chandra-ubuntu> <20081022215402.214a4ef8@plop> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from accolon.hansenpartnership.com ([76.243.235.52]:47784 "EHLO accolon.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751874AbYJVUaY (ORCPT ); Wed, 22 Oct 2008 16:30:24 -0400 In-Reply-To: <20081022215402.214a4ef8@plop> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: device-mapper development Cc: sekharan@us.ibm.com, linux-scsi@vger.kernel.org, agk@redhat.com, jens.axboe@oracle.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 > don't know how we can detect a reservation conflict from a device > handler without submitting a dangerous write io. For SCSI-2 reservations, Test Unit Ready will do this for you. For SCSI-3, you're right, it's more complex. You actually have to use the PR IN commands to read the reservations if you don't want to test what they'll actually do with an I/O. > 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 ? Well, there is a problem. Reservation Conflict should be treated as a device error and passed straight up ... it shouldn't really have any effect on dm mp because a path switch is unlikely to fix any issues. So dm mp shouldn't be intercepting this type of error at all. James