[dm-devel] Re: [BUG] dm-mpath and scsi persistent reservation

[Christophe Varoqui]

> 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