linux-kernel - Re: Integration of SCST in the mainstream Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Feb 2008 17:36:56 +0300
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
CC:	david@...g.hm, Bart Van Assche <bart.vanassche@...il.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	scst-devel@...ts.sourceforge.net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/