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:	Sat, 04 Apr 2009 23:21:04 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	Tomasz Chmielewski <mangoo@...g.org>
CC:	linux-scsi@...r.kernel.org,
	iscsitarget-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, stgt@...r.kernel.org,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	scst-devel <scst-devel@...ts.sourceforge.net>
Subject: Re: [Scst-devel] [ANNOUNCE]: Comparison of features sets between
 different SCSI targets (SCST, STGT, IET, LIO)

Tomasz Chmielewski, on 04/04/2009 11:12 PM wrote:
> Vladislav Bolkhovitin schrieb:
>> Hi All,
>>
>> I set up http://scst.sourceforge.net/comparison.html page, which 
>> compares features of existing SCSI target subsystems for Linux. The 
>> comparison includes SCST, STGT, IET and LIO.
>>
>> I might be not fully correct somewhere, so, if you don't agree with me 
>> about some item(s) in the comparison table, please let me know and I 
>> will fix that.
> 
> Performance is a bit debatable.

The result "in average" was listed in the comparison. Of course, one 
target can be better somewhere, another one somewhere else. That a 
nature of storage: it's pretty hard to optimize for all at once.

BTW, if I remember correctly your logs, you didn't apply all the SCST 
kernel patches on your kernel. Then your results aren't much applicable 
to this comparison, because it assumes all SCST kernel patches applied.

> I made some simple SCST and STGT tests last week, there were some where 
> SCST won, there were some where STGT won.
> 
> What was surprising to me, although STGT has a bigger CPU impact than 
> SCST, STGT was faster when reading from an encrypted (dm-crypt) volume, 
> on a system where the CPU is the bottleneck (it can't decrypt as fast as 
> HDD can deliver data).
> 
> STGT was much slower when reading from a non-encrypted volume, when 
> target had "blockdev --setra 16384 ..." for a given target.
> On the other hand, STGT was faster than SCST with default blockdev 
> readahead settings (256).
> 
> If anyone's interested, I can show results in a readable form on Monday 
> (right now, I have only raw data which is pretty long and would be hard 
> to compare).
> 
> 
> 

--
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