[RFC PATCH 1/1] perform some ALUA management in kernel for tcmu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Mike Christie <mchristi@xxxxxxxxxx>

For passthrough backends (modules that set TRANSPORT_FLAG_PASSTHROUGH)
we have the following problems:

1. ALUA:
	A. tcmu-runner can configure the backend ALUA groups
(/sys/kernel/config/target/core/user_0/mydev/alua), but we cannot setup
the mapping between the group and LUN
(/sys/kernel/config/target/iscsi/iqn.1999-09.com.tgt/tpgt_1/lun/lun_0/alua_tg_pt_gp) in configfs. Userspace tools/daemons have to then use two interfaces.

	B. tcmu-runner does not know what port and target port group
commands were sent through, so it cannot determine if a command is
allowed. I think target_core_pscsi would have issues with multipathd backend
devices, but I do not think that is supportable now, so I think we can ignore
it.

2. PGR:
	A. tmcu-runner and target_core_pscsi do not know the I_T Nexues being
used between LIO's exported target and the connected initiator to it.
tcmu-runner is just not passed that info currently, but device's being used by
target_core_pscsi only see the I_T Nexus between its initiator and target.

In the following patch, I tried to handle the problem 1 A and B for
tcmu-runner. The patch adds a TRANSPORT_FLAG_PASSTHROUGH_ALUA flag which
only target_core_pscsi sets. For target_core_user, lio will then allow
full ALUA setup in configfs and the ALUA state checks will be executed
in the kernel.

STPG and RTPG are still done in userspace. For STPG handling,
tcmu-runner will update the backend ALUA group
(/sys/kernel/config/target/core/user_0/mydev/alua) info. For RTPGs,
tcmu-runner will either loop over the configfs info or it could also
store the info in the daemon.

INQUIRY handling needs some work. I think that will have to be moved
back into the kernel, so page 83's relative target port ID and target
port group info can be returned for the port the inquiry was received
on. I can fix this in the next resend if this approach is ok.

To handle #2 for both tcmu-runner and target_core_pscsi, I think we need
to do something similar where the kernel handles some processing like
the reservation check, and daemons like tcmu-runner can update the kernel
PGR state when it is processing PGR commands.

An alternative for tcmu-runner would be to just pass it the ALUA to LUN mapping
durig setup, and then also pass the I_T Nexus info for each command. tcmu-runner
could then do everything it needed. However, for target_core_pscsi PGR
handling we would need to do that in LIO's common PGR code.


Signed-off-by: Mike Christie <mchristi@xxxxxxxxxx>
---
 drivers/target/target_core_alua.c    | 9 +++++----
 drivers/target/target_core_pscsi.c   | 3 ++-
 drivers/target/target_core_tpg.c     | 3 ++-
 include/target/target_core_backend.h | 3 ++-
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/target/target_core_alua.c b/drivers/target/target_core_alua.c
index f5e3300..a41bbb8 100644
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -691,7 +691,7 @@ target_alua_state_check(struct se_cmd *cmd)
 
 	if (dev->se_hba->hba_flags & HBA_FLAGS_INTERNAL_USE)
 		return 0;
-	if (dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH)
+	if (dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH_ALUA)
 		return 0;
 
 	/*
@@ -1973,7 +1973,7 @@ ssize_t core_alua_store_tg_pt_gp_info(
 	unsigned char buf[TG_PT_GROUP_NAME_BUF];
 	int move = 0;
 
-	if (dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH ||
+	if (dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH_ALUA ||
 	    (dev->se_hba->hba_flags & HBA_FLAGS_INTERNAL_USE))
 		return -ENODEV;
 
@@ -2230,7 +2230,7 @@ ssize_t core_alua_store_offline_bit(
 	unsigned long tmp;
 	int ret;
 
-	if (dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH ||
+	if (dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH_ALUA ||
 	    (dev->se_hba->hba_flags & HBA_FLAGS_INTERNAL_USE))
 		return -ENODEV;
 
@@ -2316,7 +2316,8 @@ ssize_t core_alua_store_secondary_write_metadata(
 
 int core_setup_alua(struct se_device *dev)
 {
-	if (!(dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH) &&
+	if (!(dev->transport->transport_flags &
+	     TRANSPORT_FLAG_PASSTHROUGH_ALUA) &&
 	    !(dev->se_hba->hba_flags & HBA_FLAGS_INTERNAL_USE)) {
 		struct t10_alua_lu_gp_member *lu_gp_mem;
 
diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
index 04d7aa7..438ea70 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -1103,7 +1103,8 @@ static void pscsi_req_done(struct request *req, int uptodate)
 static const struct target_backend_ops pscsi_ops = {
 	.name			= "pscsi",
 	.owner			= THIS_MODULE,
-	.transport_flags	= TRANSPORT_FLAG_PASSTHROUGH,
+	.transport_flags	= TRANSPORT_FLAG_PASSTHROUGH |
+				  TRANSPORT_FLAG_PASSTHROUGH_ALUA,
 	.attach_hba		= pscsi_attach_hba,
 	.detach_hba		= pscsi_detach_hba,
 	.pmode_enable_hba	= pscsi_pmode_enable_hba,
diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c
index d99752c..6549deb 100644
--- a/drivers/target/target_core_tpg.c
+++ b/drivers/target/target_core_tpg.c
@@ -600,7 +600,8 @@ int core_tpg_add_lun(
 	if (ret)
 		goto out_kill_ref;
 
-	if (!(dev->transport->transport_flags & TRANSPORT_FLAG_PASSTHROUGH) &&
+	if (!(dev->transport->transport_flags &
+	     TRANSPORT_FLAG_PASSTHROUGH_ALUA) &&
 	    !(dev->se_hba->hba_flags & HBA_FLAGS_INTERNAL_USE))
 		target_attach_tg_pt_gp(lun, dev->t10_alua.default_tg_pt_gp);
 
diff --git a/include/target/target_core_backend.h b/include/target/target_core_backend.h
index b54b98d..816c028 100644
--- a/include/target/target_core_backend.h
+++ b/include/target/target_core_backend.h
@@ -4,7 +4,8 @@
 #include <linux/types.h>
 #include <target/target_core_base.h>
 
-#define TRANSPORT_FLAG_PASSTHROUGH		1
+#define TRANSPORT_FLAG_PASSTHROUGH		0x1
+#define TRANSPORT_FLAG_PASSTHROUGH_ALUA		0x2
 
 struct request_queue;
 struct scatterlist;
-- 
2.7.2

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



[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux