linux-kernel - Re: [Scst-devel] Fwd: Re: linuxcon 2010...

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: <AANLkTi=vjApRS+hXA8xuNv7NkfLmgCKvQFcMBPWEUeoB@mail.gmail.com>
Date:	Tue, 24 Aug 2010 12:32:05 +0200
From:	Bart Van Assche <bvanassche@....org>
To:	James Bottomley <James.Bottomley@...e.de>
Cc:	Vladislav Bolkhovitin <vst@...b.net>,
	scst-devel <scst-devel@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...

On Mon, Aug 23, 2010 at 10:38 PM, James Bottomley
<James.Bottomley@...e.de> wrote:
> On Mon, 2010-08-23 at 23:40 +0400, Vladislav Bolkhovitin wrote:
>> James Bottomley, on 08/23/2010 08:59 PM wrote:
>> > My basic conclusion was that there's no incredible discriminator between
>> > LIO and STGT (although there are reams written on which performs better
>> > in which circumsances, is useful for clustering, supports ALUA, etc.
>> > each with partisans for the features).
>>
>> Here is a comprehensive features comparison I prepared some time ago:
>> http://scst.sourceforge.net/comparison.html. It's a bit outdated at the
>> moment, but I'm going to make it completely up do date in the next few days.
>
> That's not really going to help ... I don't really want another 500 mail
> thread of partisan yelling about which is better.  I'm happy to concede
> that either could beat the other on a given set of well chosen tests ...
> but knowing that is completely useless to me.  I can also guess, given
> the antipathy, that neither of you would agree on a definitive set of
> comparison tests.
>
> So it comes down to a community test instead: which works better with
> the community.  This is important to me because it's an indication of
> what might ensue once code goes upstream and thus moves outside the
> exclusive province of the project to become a community resource. STGT
> is a community too and so far what you seem to have told me is:
>
>      * STGT users should just migrate to scst_local
>      * STGT doesn't have enough users to bother with
>      * STGT has fundamental design flaws which makes its pass through
>        architecture unusable and its ABI flawed.
>
> I'm sure STGT appreciates the frank assessments, but it doesn't seem to
> merit too many "plays well with others" points.

Although it may not be clear from this thread, we respect the STGT
software and the all work the STGT authors have done to make it a
successful, stable and high performance storage target. The iSCSI-SCST
target driver even contains some of the code that was originally
written by an STGT author (Tomo) for a different project (IET).

A lot has already been discussed in this thread. It is already clear
that integrating LIO instead of SCST would hurt many SCST users. What
is not yet clear is what the consequences would be for LIO users if
SCST would be integrated instead of LIO ? A few months SCST has gained
support for persistent reservations (clustering). The SCSI engine of
SCST is powerful, and the core - target driver interface of SCST is a
rich interface. If there are any user-developed LIO target drivers,
it's probably relatively easy to port these to SCST.

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