On Fri, 2008-02-08 at 17:36 +0300, Vladislav Bolkhovitin wrote: > Nicholas A. Bellinger wrote: > >>>>- It has been discussed which iSCSI target implementation should be in > >>>>the mainstream Linux kernel. There is no agreement on this subject > >>>>yet. The short-term options are as follows: > >>>>1) Do not integrate any new iSCSI target implementation in the > >>>>mainstream Linux kernel. > >>>>2) Add one of the existing in-kernel iSCSI target implementations to > >>>>the kernel, e.g. SCST or PyX/LIO. > >>>>3) Create a new in-kernel iSCSI target implementation that combines > >>>>the advantages of the existing iSCSI kernel target implementations > >>>>(iETD, STGT, SCST and PyX/LIO). > >>>> > >>>>As an iSCSI user, I prefer option (3). The big question is whether the > >>>>various storage target authors agree with this ? > >>> > >>>I tend to agree with some important notes: > >>> > >>>1. IET should be excluded from this list, iSCSI-SCST is IET updated for SCST > >>>framework with a lot of bugfixes and improvements. > >>> > >>>2. I think, everybody will agree that Linux iSCSI target should work over > >>>some standard SCSI target framework. Hence the choice gets narrower: SCST vs > >>>STGT. I don't think there's a way for a dedicated iSCSI target (i.e. PyX/LIO) > >>>in the mainline, because of a lot of code duplication. Nicholas could decide > >>>to move to either existing framework (although, frankly, I don't think > >>>there's a possibility for in-kernel iSCSI target and user space SCSI target > >>>framework) and if he decide to go with SCST, I'll be glad to offer my help > >>>and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. The > >>>better one should win. > >> > >>why should linux as an iSCSI target be limited to passthrough to a SCSI > >>device. > > > > <nod> > > > > I don't think anyone is saying it should be. It makes sense that the > > more mature SCSI engines that have working code will be providing alot > > of the foundation as we talk about options.. > > > >>From comparing the designs of SCST and LIO-SE, we know that SCST has > > supports very SCSI specific target mode hardware, including software > > target mode forks of other kernel code. This code for the target mode > > pSCSI, FC and SAS control paths (more for the state machines, that CDB > > emulation) that will most likely never need to be emulated on non SCSI > > target engine. > > ...but required for SCSI. So, it must be, anyway. > > > SCST has support for the most SCSI fabric protocols of > > the group (although it is lacking iSER) while the LIO-SE only supports > > traditional iSCSI using Linux/IP (this means TCP, SCTP and IPv6). The > > design of LIO-SE was to make every iSCSI initiator that sends SCSI CDBs > > and data to talk to every potential device in the Linux storage stack on > > the largest amount of hardware architectures possible. > > > > Most of the iSCSI Initiators I know (including non Linux) do not rely on > > heavy SCSI task management, and I think this would be a lower priority > > item to get real SCSI specific recovery in the traditional iSCSI target > > for users. Espically things like SCSI target mode queue locking > > (affectionally called Auto Contingent Allegiance) make no sense for > > traditional iSCSI or iSER, because CmdSN rules are doing this for us. > > Sorry, it isn't correct. ACA provides possibility to lock commands queue > in case of CHECK CONDITION, so allows to keep commands execution order > in case of errors. CmdSN keeps commands execution order only in case of > success, in case of error the next queued command will be executed > immediately after the failed one, although application might require to > have all subsequent after the failed one commands aborted. Think about > journaled file systems, for instance. Also ACA allows to retry the > failed command and then resume the queue. > Fair enough. The point I was making is that I have never actually seen an iSCSI Initiator use ACA functionality (I don't believe that the Linux SCSI Ml implements this), or actually generate a CLEAR_ACA task management request. --nab > Vlad > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
