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]
Message-ID: <alpine.DEB.1.00.0802071437404.12791@asgard.lang.hm>
Date:	Thu, 7 Feb 2008 14:51:48 -0800 (PST)
From:	david@...g.hm
To:	Vladislav Bolkhovitin <vst@...b.net>
cc:	Bart Van Assche <bart.vanassche@...il.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	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 Thu, 7 Feb 2008, Vladislav Bolkhovitin wrote:

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

the most common use of this sort of thing that I would see is to load up a 
bunch of 1TB SATA drives in a commodity PC, run software RAID, and then 
export the resulting volume to other servers via iSCSI. not a 'real' SCSI 
device in sight.

As far as how good a standard iSCSI is, at this point I don't think it 
really matters. There are too many devices and manufacturers out there 
that implement iSCSI as their storage protocol (from both sides, offering 
storage to other systems, and using external storage). Sometimes the best 
technology doesn't win, but Linux should be interoperable with as much as 
possible and be ready to support the winners and the loosers in technology 
options, for as long as anyone chooses to use the old equipment (after 
all, we support things like Arcnet networking, which lost to Ethernet many 
years ago)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ