[PATCH] [Target_Core_Mod/STGT]: Add struct Scsi_Host target infrastructure WIP

Greetings all,

This patch adds the first pieces of a v3.x subsystem plugin that interacts
with Linux/SCSI to create a virtual target mode struct Scsi_Host, and using
userspace backstores from the existing STGT codebase.

So far, creating and removing STGT virtual target HBAs in through ConfigFS is
working and status appearing under /sys/bus/stgt_bus and /sys/class/scsi_host/host#/

Most of the code required for actual STGT struct scsi_cmnd is in place
(but not-tested yet), and the next main step is hooking up stgt_create_virtdevice()
in drivers/target/target_core_stgt.c to assoicate the userspace backstore
attached to the Target_Core_Mod/STGT virtual SCSI target mode HBA.

The long term goal to allow all kernel level fabric modules to take advantage of the
upstream STGT code in drivers/scsi/scsi_tgt_[if,lib].c.

Here is what the running code looks like:

*) tree /sys/kernel/config/target/core/

/sys/kernel/config/target/core/
|-- alua
|   |-- lu_gps
|   |   `-- default_lu_gp
|   |       |-- alua_access_state
|   |       |-- lu_gp_id
|   |       `-- members
|   `-- tg_pt_gps
|       `-- default_tg_pt_gp

Re: Fwd: Delivery Status Notification (Failure)

On Fri, 19 Sep 2008 17:01:44 +0530
"aniket agashe" <agasheac@...> wrote:

> Sir
>  i have 2 machines A & B
> i installed iser initiator on A and target on B where i am using RAID disk
> as target
> i have installed ext3 on raid disk after creating login session with B, i
> mounted file system on the disk which is visible to the A machine on the A
> machine
> 
> 
> 
> but whenever i am creating new file on A machine on the file system which is
> mounted it is visible to local machine(B) as -

First, please use stgt@...

stgt-devel@... doesn't accept mails any more.

Second, what you try to do is not impossible with the combination of
iSCSI and ext3.

Just use NFS. If you want iSER, you need to use a cluseter file system
like GFS.

Re: LVM2 vs FileIO - pros/cons?

On Wed, 2008-09-10 at 10:16 -0700, Martin wrote:
> If I have space presented to my iscsi host as a large hw-based LUN,
> and I would like to provide that to initiators in several chunks
> through multiple targets, am I best off dividing up the space using
> the FileIO hba type, or setting up LVM2, or another option?  What are
> the pros and cons of the possible choices?
> 

So, the targets communicate with LVM2's device-mapper struct
block_device using struct bio requets that employs *UNBUFFERED*
opteration.  That is, acknowledgements for iSCSI I/O CDBs get sent back
to the Initiator Port (or client or whatever you want to call it) *ONLY*
when the underlying storage tells it it has be put down to the media.
If you are using a hardware RAID, this means that the request may be
going into a write-back or write-through memory cache before it actually
goes down to disk.  With a hardware RAID, you need a battery backup in
order to ensure data integrity across a power failure.  There is a
limitiation with kernel level FILEIO where O_DIRECT is unimplemented on
kernel level memory pages, which means only *BUFFERED* ops are supported
on FILEIO.  If a machine was to crash and then restart with the same
kernel level export, the initiator side would have the incorrect view of
the actual blocks on media.  NOT GOOD..  Same type of problem if your
hardware RAID does has write cache enabled and *NO* battery backup.

A transport layer like SCSI or SATA is a DMA ring to hardware, and has
no concept of buffers, they just queue requests into the hardware ring
and out onto the BUS, etc.  The same type of unbuffered option is
happens for a SCSI passthrough (eg, LIO-Target hba_type=1).  Using
struct scsi_device as a target engine storage object in kernel space
*REQUIRES* this type of unbuffered I/O, and actually happens to be the

the old mailing list will be closed

Hi,

As I noticed a week ago, we moved stgt mailing list to
vger.kernel.org. If you have not subscribed to the new mailing list,
please subscribe:

http://vger.kernel.org/vger-lists.html#stgt

I'll change the configuration that nobody can post to the old mailing
list, stgt-devel@...

Thanks,

Rolex, Rado, Patek Philippe, Omegga, Gucci

_______________________________________________
Stgt-devel mailing list
Stgt-devel@...
https://lists.berlios.de/mailman/listinfo/stgt-devel

[PATCH 2/2] Take 2: Implement smc INITIALIZE ELEMENT STATUS WITH RANGE

commit d8c5617849c15d54c0ebd2efbc9f16161a6f2e56
Author: Mark Harvey <markh794@...>
Date:   Wed Aug 20 10:58:02 2008 +1000

    Implement smc INITIALIZE ELEMENT STATUS WITH RANGE op code as NO-OP

    - Implemented INITIALIZE ELEMENT STATUS WITH RANGE as a No Operation.

    Reported-by: Richard Sharpe <realrichardsharpe@...>
    Signed-off-by: Mark Harvey <markh794@...>

diff --git a/usr/smc.c b/usr/smc.c
index e735deb..ab36e9c 100644
--- a/usr/smc.c
+++ b/usr/smc.c
 <at>  <at>  -225,6 +225,23  <at>  <at>  static int build_element_descriptors(uint8_t *data, struct
list_head *head,
 }

 /**
+ * smc_initialize_element_status with range
+ *                      - INITIALIZE ELEMENT STATUS WITH RANGE op code
+ *
+ * Support the SCSI op code INITIALIZE_ELEMENT_STATUS_WITH_RANGE
+ * Ref: smc3r11, 6.5
+ */
+static int smc_initialize_element_status_range(int host_no, struct scsi_cmd *cm
d)
+{
+       scsi_set_in_resid_by_actual(cmd, 0);
+
+       if (device_reserved(cmd))
+               return SAM_STAT_RESERVATION_CONFLICT;
+       else
+               return SAM_STAT_GOOD;
+}
+
+/**
  * smc_initialize_element_status - INITIALIZE ELEMENT STATUS op code
  *
  * Some backup libraries seem to require this.
 <at>  <at>  -796,7 +813,28  <at>  <at>  struct device_type_template smc_template = {
                {spc_illegal_op,},
                {spc_illegal_op,},

-               [0x20 ... 0x4f] = {spc_illegal_op,},
+               [0x20 ... 0x2f] = {spc_illegal_op,},
+
+               /* 0x30 */
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {smc_initialize_element_status_range,},
+
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+               {spc_illegal_op,},
+
+               [0x40 ... 0x4f] = {spc_illegal_op,},

                /* 0x50 */
                {spc_illegal_op,},

_______________________________________________
Stgt-devel mailing list
Stgt-devel@...
https://lists.berlios.de/mailman/listinfo/stgt-devel

[PATCH 1/2] Take 2: Implement smc INITIALIZE ELEMENT STATUS

Added test for SCSI RESERVATION.

Still implemented as a no-op.

(Attached patch due to gmail web mangling whitespaces).

commit de9949ce821ed1bca9d60e8d98ec806c3c80ec6b
Author: Mark Harvey <markh794@...>
Date:   Wed Aug 20 10:48:57 2008 +1000

    Implement smc INITIALIZE ELEMENT STATUS op code as NO-OP

    Re-submit Richard Sharpe's patch in git format

    Added test for reservation.

    Reported-by: Richard Sharpe <realrichardsharpe@...>
    Signed-off-by: Mark Harvey <markh794@...>

diff --git a/usr/smc.c b/usr/smc.c
index 9d7f681..e735deb 100644
--- a/usr/smc.c
+++ b/usr/smc.c
 <at>  <at>  -225,6 +225,24  <at>  <at>  static int build_element_descriptors(uint8_t *data, struct
list_head *head,
 }

 /**
+ * smc_initialize_element_status - INITIALIZE ELEMENT STATUS op code
+ *
+ * Some backup libraries seem to require this.
+ *
+ * Support the SCSI op code INITIALIZE_ELEMENT_STATUS
+ * Ref: smc3r10a, 6.2
+ */
+static int smc_initialize_element_status(int host_no, struct scsi_cmd *cmd)
+{
+       scsi_set_in_resid_by_actual(cmd, 0);
+
+       if (device_reserved(cmd))
+               return SAM_STAT_RESERVATION_CONFLICT;
+       else
+               return SAM_STAT_GOOD;
+}
+
+/**
  * smc_read_element_status  -  READ ELEMENT STATUS op code
  *
  * Support the SCSI op code READ ELEMENT STATUS
 <at>  <at>  -748,7 +766,7  <at>  <at>  struct device_type_template smc_template = {
                {spc_illegal_op,},
                {spc_illegal_op,},
                {spc_illegal_op,},
-               {spc_illegal_op,},
+               {smc_initialize_element_status,},

                {spc_illegal_op,},
                {spc_illegal_op,},

_______________________________________________
Stgt-devel mailing list
Stgt-devel@...
https://lists.berlios.de/mailman/listinfo/stgt-devel

[PATCH 2/2] Implement smc INITIALIZE ELEMENT STATUS WITH RANGE

From 6ea07a536dcc3fe89f11d46bfadd3cafca75c911 Mon Sep 17 00:00:00 2001
From: Mark Harvey <markh794@...>
Date: Tue, 19 Aug 2008 09:41:47 +1000
Subject: Implement smc INITIALIZE ELEMENT STATUS WITH RANGE as NO-OP

Signed-off-by: Mark Harvey <markh794@...>
---
 usr/smc.c |   39 ++++++++++++++++++++++++++++++++++++++-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/usr/smc.c b/usr/smc.c
index a04e905..d2dda4f 100644
--- a/usr/smc.c
+++ b/usr/smc.c
 <at>  <at>  -225,6 +225,22  <at>  <at>  static int build_element_descriptors(uint8_t *data, struct list_head *head,
 }

 /**
+ * smc_initialize_element_status with range
+ *                      - INITIALIZE ELEMENT STATUS WITH RANGE op code
+ *
+ * Support the SCSI op code INITIALIZE_ELEMENT_STATUS_WITH_RANGE
+ * Ref: smc3r11, 6.5
+ */
+static int smc_initialize_element_status_range(int host_no, struct scsi_cmd *cmd)
+{
+	/*
+	 * Should do some error checking here ... the spec says some stuff
+	 * about having a reservation
+	 */
+	return SAM_STAT_GOOD;
+}
+
+/**
  * smc_initialize_element_status - INITIALIZE ELEMENT STATUS op code
  *
  * Some backup libraries seem to require this.
 <at>  <at>  -795,7 +811,28  <at>  <at>  struct device_type_template smc_template = {
 		{spc_illegal_op,},
 		{spc_illegal_op,},

-		[0x20 ... 0x4f] = {spc_illegal_op,},
+		[0x20 ... 0x2f] = {spc_illegal_op,},
+
+		/* 0x30 */
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{smc_initialize_element_status_range,},
+
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+		{spc_illegal_op,},
+
+		[0x40 ... 0x4f] = {spc_illegal_op,},

 		/* 0x50 */
 		{spc_illegal_op,},
--

-- 
1.5.4.3

SSC Changes that allow BakBone NetVault to work ...

Hi,

Attached are the diffs for my current SSC implementation. These
changes, along with the diffs I posted for SMC, allow BakBone to work,
to see a Tape Library, and to backup to tapes in the library.

There are undoubtedly many problems with the code, not the least of
which is that it is pretty ugly 

One thing I note is that the latest drafts of SSC and SMC support the
READ_ATTRIBUTES command, with SMC allowing the reading of attributes
from tapes in media slots. Thus, the current ssc.h definitions for MAM
seem incomplete. I would suggest a common set of routines for dealing
MAM in bot SSC and SMC.

_______________________________________________
Stgt-devel mailing list
Stgt-devel@...
https://lists.berlios.de/mailman/listinfo/stgt-devel

Dealing with virtual tapes when they are moved out of a drive ...

Hi,

It strikes me that one might want to deal with virtual tapes when they
are moved out of a virtual tape drive and back to a slot.

This might take the form of a script that the sys admin provides that
does something special with the tape or whatever.

Here is one possible approach to doing that (I have not fully
implemented it, I only throw this out as a possibility):

--- smc.c       2008-08-15 16:12:26.000000000 -0700
+++ smc.c.dispose-tape  2008-08-17 11:47:33.000000000 -0700
 <at>  <at>  -457,9 +457,21  <at>  <at> 
                        asc = ASC_MECHANICAL_POSITIONING_ERROR;
                        goto sense;
                }
-       } else
+       } else {
                set_slot_full(dest_slot, src, NULL);

+               /*
+                * Now, if the source slot was a data transfer element
+                * execute any unload script provided ...
+                */
+               if (src_slot->element_type == ELEMENT_DATA_TRANSFER) {
+
+                       /*
+                        * execve etc ...
+                        */
+               }
+       }
+
        set_slot_empty(src_slot);

        scsi_set_in_resid_by_actual(cmd, 0);

Testing ... 123

Hi,

Sun allows you to download a trial version of BakBone's NetVault ...
very useful.