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, 15 Feb 2008 16:02:47 +0100
From:	"Bart Van Assche" <bart.vanassche@...il.com>
To:	"Vladislav Bolkhovitin" <vst@...b.net>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Cc:	"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>
Subject: Re: Integration of SCST in the mainstream Linux kernel

On Thu, Feb 7, 2008 at 2:45 PM, Vladislav Bolkhovitin <vst@...b.net> wrote:
>
> Bart Van Assche wrote:
>  > Since the focus of this thread shifted somewhat in the last few
>  > messages, I'll try to summarize what has been discussed so far:
>  > - There was a number of participants who joined this discussion
>  > spontaneously. This suggests that there is considerable interest in
>  > networked storage and iSCSI.
>  > - It has been motivated why iSCSI makes sense as a storage protocol
>  > (compared to ATA over Ethernet and Fibre Channel over Ethernet).
>  > - The direct I/O performance results for block transfer sizes below 64
>  > KB are a meaningful benchmark for storage target implementations.
>  > - It has been discussed whether an iSCSI target should be implemented
>  > in user space or in kernel space. It is clear now that an
>  > implementation in the kernel can be made faster than a user space
>  > implementation (http://kerneltrap.org/mailarchive/linux-kernel/2008/2/4/714804).
>  > Regarding existing implementations, measurements have a.o. shown that
>  > SCST is faster than STGT (30% with the following setup: iSCSI via
>  > IPoIB and direct I/O block transfers with a size of 512 bytes).
>  > - 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.

If I understood the above correctly, regarding a kernel space iSCSI
target implementation, only LIO-SE and SCST should be considered. What
I know today about these Linux iSCSI target implementations is as
follows:
* SCST performs slightly better than LIO-SE, and LIO-SE performs
slightly better than STGT (both with regard to latency and with regard
to bandwidth).
* The coding style of SCST is closer to the Linux kernel coding style
than the coding style of the LIO-SE project.
* The structure of SCST is closer to what Linus expects than the
structure of LIO-SE (i.e., authentication handled in userspace, data
transfer handled by the kernel -- LIO-SE handles both in kernel
space).
* Until now I did not encounter any strange behavior in SCST. The
issues I encountered with LIO-SE are being resolved via the LIO-SE
mailing list (http://groups.google.com/group/linux-iscsi-target-dev).

It would take too much effort to develop a new kernel space iSCSI
target from scratch -- we should start from either LIO-SE or SCST. My
opinion is that the best approach is to start with integrating SCST in
the mainstream kernel, and that the more advanced features from LIO-SE
that are not yet in SCST can be ported from LIO-SE to the SCST
framework.

Nicholas, do you think the structure of SCST is powerful enough to be
extended with LIO-SE's powerful features like ERL-2 ?

Bart Van Assche.
--
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/