Is the SPC-3 reservation support the same in when Quadstor is installed on Linux or FreeBSD?

150 views
Skip to first unread message

Patrick Dung

unread,
Aug 3, 2013, 12:05:04 PM8/3/13
to quadst...@googlegroups.com
As I know, ietd is used/ported for the iscsi target.

I have done some testing:

I have two RHEL clusters and want to use the SPC-3 scsi reservation over iscsi.

When the iscsi server/quadstor-virt is installed on Linux, the result is ok.
But when it is installed on FreeBSD, I found client side have problem like scsi reservation conflict.

Please advise.

QUADStor Support

unread,
Aug 3, 2013, 12:40:49 PM8/3/13
to quadst...@googlegroups.com
Thanks for reporting this. A few clarifications

1. The core code consists of thin provisioning, clustering, HA, vdisk
emulation etc. This is independent of which interface the SCSI
commands are received from. There are certain callbacks which an
interface needs to implement in order that a client can access a VDisk
over that interface.
2. Now, we have modified IET for iSCSI, qlogic driver for FC and SRPT
driver for infiniband to implement these callbacks and send/received
commands.
3. So anything that applies to IET do not necessarily apply to
QUADStor. In order to minimize the effort of taking changes back from
IET, most of the filenames, code remain the same. But on closer
examination you will find that most of the disk read/write, lun logic
isn't there since we dont need it.
4. Point (1) and (3) also applies for the persistent reservation code.
In fact QUADStor was responsible for providing the initial patch to
add persistent reservation code to IET. However while the logic for
persistent reservation is similar, the similarity stops there. Any
issues with quadstor persistent reservation implementation will not
apply to IET and vice versa

The problem you mention seems to be similar to the issue you are
facing with the VTL code on FreeBSD. We did notice a few reservation
conflicts in your logs then. This is assuming that you are using
FreeBSD 9.1. Kindly send across the logs (off list) so that we could
confirm its the same issue.

And assuming that its the same issue, then its down to the iSCSI code
for the OS in use. We have a fix which we are testing for the VTL code
and may be the same fix applies.

Patrick Dung

unread,
Aug 3, 2013, 1:02:53 PM8/3/13
to quadst...@googlegroups.com
Thanks for the prompt respond.

Yes, I used FreeBSD 9.1 for the test.
For the cluster testing, I did the scsi reservation test some time ago. I hope I could find that log later.

For your information about using FreeBSD as iscsi target and the RHEL clusters:
When I tested the spc-3 persistent reservation using FreeBSD's port istgt (http://www.peach.ne.jp/archives/istgt/)
It claimed that it supported SPC-3 persistent reservation but still got problem.

QUADStor Support

unread,
Aug 3, 2013, 2:03:10 PM8/3/13
to quadst...@googlegroups.com
On 8/3/13, Patrick Dung <mpat...@gmail.com> wrote:
> Thanks for the prompt respond.
>
> Yes, I used FreeBSD 9.1 for the test.
> For the cluster testing, I did the scsi reservation test some time ago. I
> hope I could find that log later.

Then you would like to try again. A couple of weeks back we did a few
fixes specific to persistent reservations. That would be in 3.0.40 and
3.0.41
Which is the application/tool used for testing ?

> For your information about using FreeBSD as iscsi target and the RHEL
> clusters:
> When I tested the spc-3 persistent reservation using FreeBSD's port istgt
> (http://www.peach.ne.jp/archives/istgt/)
> It claimed that it supported SPC-3 persistent reservation but still got
> problem.

You would report it with the istgt maintainers. For FreeBSD you could
also try https://github.com/quadstor/ietbsd/ . This is the IET port
for FreeBSD which we unofficially maintain.
> --
> You received this message because you are subscribed to the Google Groups
> "QUADStor Storage Virtualization" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to quadstor-vir...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
Reply all
Reply to author
Forward
0 new messages