Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759085AbYBHOhT (ORCPT ); Fri, 8 Feb 2008 09:37:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756657AbYBHOhD (ORCPT ); Fri, 8 Feb 2008 09:37:03 -0500 Received: from mail-relay-01.mailcluster.net ([77.221.130.213]:42336 "EHLO mail-relay-01.mailcluster.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbYBHOhA (ORCPT ); Fri, 8 Feb 2008 09:37:00 -0500 Message-ID: <47AC6908.7060809@vlnb.net> Date: Fri, 08 Feb 2008 17:36:56 +0300 From: Vladislav Bolkhovitin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-us, ru, en MIME-Version: 1.0 To: "Nicholas A. Bellinger" CC: david@lang.hm, Bart Van Assche , James Bottomley , FUJITA Tomonori , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, scst-devel@lists.sourceforge.net, Andrew Morton , Linus Torvalds Subject: Re: Integration of SCST in the mainstream Linux kernel References: <1202144767.3096.38.camel@localhost.localdomain> <47A7488B.4080000@vlnb.net> <1202145901.3096.49.camel@localhost.localdomain> <47A751C5.60600@vlnb.net> <1202149322.3096.66.camel@localhost.localdomain> <47A75B8A.3020503@vlnb.net> <1202151293.3096.80.camel@localhost.localdomain> <47A8B210.8040202@vlnb.net> <1202238802.3133.71.camel@localhost.localdomain> <47AB0B63.20500@vlnb.net> <1202470395.1805.127.camel@haakon2.linux-iscsi.org> In-Reply-To: <1202470395.1805.127.camel@haakon2.linux-iscsi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3963 Lines: 77 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. > > > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/