From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christophe Varoqui Subject: Re: [BUG] dm-mpath and scsi persistent reservation Date: Thu, 23 Oct 2008 23:03:21 +0200 Message-ID: <20081023230321.6efe92a1@plop> References: <20081021231910.0fdbeb75@plop> <1224629283.14830.838.camel@chandra-ubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from smtp4-g19.free.fr ([212.27.42.30]:58766 "EHLO smtp4-g19.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753672AbYJWVD0 convert rfc822-to-8bit (ORCPT ); Thu, 23 Oct 2008 17:03:26 -0400 In-Reply-To: <1224629283.14830.838.camel@chandra-ubuntu> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: james.bottomley@hansenpartnership.com Cc: sekharan@us.ibm.com, jens.axboe@oracle.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 don't know how we can detect a reservation > > conflict from a device handler without submitting a dangerous write > > io. >=20 > For SCSI-2 reservations, Test Unit Ready will do this for you. >=20 > For SCSI-3, you're right, it's more complex. You actually have to us= e > the PR IN commands to read the reservations if you don't want to test > what they'll actually do with an I/O. >=20 The PR-IN "READ FULL STATUS" looked promising indeed, bu does not work on any storage hardware I tried. Always ends up there (in sg_persist.c) : 293 else if (SG_LIB_CAT_ILLEGAL_REQ =3D=3D res) 294 fprintf(stderr, "PR in: bad field in cdb including " 295 "unsupported service action\n"); Other PR-INs would list the registration keys and reservation, but how would we know from the kernel or from userspace multipath which keys are associated with host's I_T nexus ? The key would likely have been registered by a userspace clusterware for fencing purpose. PR-OUT "REGISTER" with params rk=3D0 sark=3D0 may trigger a significati= ve difference when send over a registered I_T or not (based on SPC-3 - Table 33 =E2=80=94 Register behaviors for a REGISTER service action). Did you have something different in mind ? > > 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 ? >=20 > 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. >=20 Well, a path switch might be a valid behaviour considering persistent reservations are per I_T nexus ... the io may succeed if submited from another intiator for example. But anyway, if all paths failed the io should not be queued. Regards, cvaroqui -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html