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.
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
