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]

Date:	Mon, 23 Aug 2010 09:47:23 -0400
From:	Joe Landman <landman@...lableinformatics.com>
To:	James Bottomley <James.Bottomley@...e.de>
CC:	Bart Van Assche <bvanassche@....org>,
	Vladislav Bolkhovitin <vst@...b.net>,
	linux-scsi@...r.kernel.org, Chetan Loke <chetanloke@...il.com>,
	linux-kernel@...r.kernel.org,
	scst-devel <scst-devel@...ts.sourceforge.net>
Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...

James Bottomley wrote:

> So the phrase "up to GigE" was deliberately in the above to exclude the
> disputed infiniband results.  I'm not really interested in re-opening
> the arguments over how to interpret those results.  The fact that SCST
> and STGT were on par up to 1GbE is enough to refute the contention that
> STGT is "fundamentally slow".

We haven't tested this in at least 6 months, but we did test iSCSI over 
10GbE using SCST and STGT.  This was one of the reasons we wound up 
going with SCST.  For the past several years, our performance on SCST 
was much higher than on STGT.

If it helps, we can redo these tests with a modern kernel (2.6.35.x) and 
same backend/frontend.  We've been switching most of our IO performance 
testing to Jens Axboe's excellent fio tool.  I'd be happy to share our 
testing decks with anyone (and collaborate on generating a good useful 
set for general use)

This said, I have to add in my support to SCST and its developers. 
Vlad, Bart, and the rest of the community have been very helpful to us. 
  We have been a consumer rather than a developer to date, so we have 
less of a dog in this fight than others.  We have nothing against LIO or 
STGT.  We will try them and see if they meet our needs.  SRP is a hard 
requirement, and it exists and works great in SCST.  So for us, a 
solution which gives us the best of all worlds would be one where we 
don't have to give up what works well for us, and gets us new 
capabilities/features.  This is more of a wish-list ... we have to keep 
using what works well for us.

Our interest in STGT is that we would like a working iSER.  Vlad has 
suggested a method that we will explore a little later on (next
month).  The LIO folks do look like they have some interesting 
capabilities beyond this, so we will look.  But without SRP, and a fast 
iSCSI, their really isn't much choice for us in the near term.

Regards,

Joe

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: landman@...lableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615
--
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/