lkml.org 
[lkml]   [2008]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Integration of SCST in the mainstream Linux kernel
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


\
 
 \ /
  Last update: 2008-02-08 15:39    [W:0.132 / U:1.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site