> 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. > 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 == 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=0 sark=0 may trigger a significative difference when send over a registered I_T or not (based on SPC-3 - Table 33 — 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 ? > > 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. > 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
