Hi Mike & Andy, (Adding the list CC' back) On Tue, 2017-02-07 at 12:53 -0600, Mike Christie wrote: > Hey Nick, > > Do you have any comments on this? > > I am thinking if the general approach in this patch is not ok and we > still want everything done in userpsace then for target_core_user we can > do something like tgt did. In this approach when a I_T Nexus is > established, the kernel sends a notification to userspace. The info sent > to userspace will be the expected SCSI info like initiator and target > port values, plus a LIO managed I_T Nexus ID which is just some int. > When a SCSI command is sent to userspace we then send it with the I_T > Nexus ID. > > This will also require creating a separate ALUA and LU group management > interface. I am thinking targetcli/rtslib will just talk directly to > tcmu-runner to pass it ALUA info. I don't have a particular objection to the approach below, and it would certainly be cleaner than having to introduce a second ALUA and LU group management interface in configfs that is specific to target_core_user. > > For pscsi we are just screwed and you just can't reliably use PGRs and > ALUA might be slightly messed up (depends on the setup I guess). > I don't think this use case as come in up a really long time, unless folks who use TYPE_TAPE with VTL or otherwise want this type of functionality. > > On 01/18/2017 03:51 AM, mchristi@xxxxxxxxxx wrote: > > 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. Makes sense to me, that makes it alot easier than having to reproduce a bunch of ALUA emulation and state logic in userspace. > > > > 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. I really like the idea of target_core_user driving configfs layout read/write for RTPG/STPG> > > > > 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. > > Yeah, I never understood the reason was to not do INQUIRY emulation in kernel space. It makes development target_core_user backends that much easier for end-users. > > 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. > > Also makes sense. > > 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. > > I really don't have strong feels either way on this one. -- 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
