James Bottomley wrote:
On Fri, 2008-05-02 at 18:06 +0200, Bart Van Assche wrote:
On Fri, May 2, 2008 at 5:55 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
On Fri, May 02, 2008 at 05:53:22PM +0200, Bart Van Assche wrote:
Regarding out-of-tree modules: this is just a preparatory step before
submitting SCST for inclusion in the mainstream kernel.
And what crackpipe did you smoke to thing we'd put duplicated target
framework in?
Why are you so aggressive ? I didn't insult you in any way.
Regarding inclusion of SCSI target code in the mainline, this subject
has already been discussed extensively in the past
(http://lkml.org/lkml/2008/1/23/134). The conclusion was clear: SCST
is faster than any other existing iSCSI target for Linux (IET, STGT,
LIO), stable, well maintained and the most standards compliant target.
Why do you want to reopen this discussion ?
That's an interesting rewrite of history. The evidence you presented
showed fairly identical results apart from on one contrived IB benchmark
that couldn't directly compare the two.
I'm also on record in the thread saying that was insufficient proof for
me to justify throwing STGT out and replacing it with SCST.
James, why do you keep ignoring important points, written by me in that
e-mail: http://lkml.org/lkml/2008/1/30/178?
Namely:
1. Solid architecture of SCST is inherently more simple than distributed
user/kernel space processing, when kernel behaves under control of user
space, used in STGT, and allows to get better results with less effort.
Better in all aspects: simplicity (hence, maintainability), reliability
and performance. Linux once made step away from microkernel based design
and that was for really good reasons.
2. Zero-copy operations with page cache will halve processing latency on
high speed links, like InfiniBand, and it is impossible to implement
that in a sane way with STGT approach, while for SCST it can be
implemented simply and naturally.
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
