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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 08 Feb 2008 15:53:03 -0800
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Vladislav Bolkhovitin <vst@...b.net>
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

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