[stgt] Support for persistent reservations

[FUJITA Tomonori]

On Fri, 1 Oct 2010 09:56:43 -0700
Mike Anderson <andmike at linux.vnet.ibm.com> wrote:

> Lars Kellogg-Stedman <lars at oddbit.com> wrote:
> > Hello all,
> > 
> > The fence_scsi method provided with RedHat's cman package uses SCSI
> > persistent reservations as an i/o fencing mechanism.  I've tried using
> > this against an iSCSI target served by tgtd without much luck.
> > 
> > The tool is able to successfully create a reservation by running:
> > 
> >   sg_persist -n -d <device> -o -R -K <key> -T 5
> > 
> > fence_scsi uses --preempt-abort to fence another node (prevent it from
> > accessing a device) by running:
> > 
> >   sg_persist -n -d <device> -o -A -K <local key> -S <other key> -T 5
> > 
> > This results in the following error from sg_persist:
> > 
> >   PR out: bad field in cdb including unsupported service action
> > 
> > I'm using the version of scsi-target-utils distributed with Fedora 13
> > (scsi-target-utils-1.0.1-4.fc13.x86_64).  Has anyone else run into
> > these problems?  Is this expected to work?
> > 
> > The tgt configuration looks like this:
> > 
> >   default-driver iscsi
> > 
> >   <target iqn.2001-04.com.obliquity-tgt-1>
> > 	backing-store /var/lib/libvirt/images/shared.img
> >   </target>
> > 
> > I see the same error message with tgtd 1.0.9.  Additionally, both
> > versions appear to freeze up completely if I try to use --preempt
> > instead of --preempt-abort.
> 
> The PR_OUT_PREEMPT_AND_ABORT service action is currently not supported.
> You may have already seen this by the commented out service action in
> spc.c.
> 
> I am seeing the freeze also. We are in a endless goto loop in
> spc_pr_preempt based on a non-zero service action key.
> 
> Working on a patch for the --preempt case now by verifying the code vs.
> the preempt flow chart in the spc specification. I assume you are more
> interested in the support for --preempt-abort.

Yeah, my NetApp box doesn't support PR_OUT_PREEMPT_AND_ABORT too.


> I will look at this next
> unless others are already working on it.

I apprecate you if you could look at the above endless loop bug.

Thanks in advance.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html