James Bottomley, on 08/24/2010 12:38 AM 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.
Hmm, the comparison page isn't supposed to contain a set of tests which
one implementation can pass or another. It is supposed to help reviewing
different implementations and give a reviewer a clue where to look to
see the difference. I believe that for such highly experienced person
like you it wouldn't take much effort to find the corresponding code and
verify it.
For instance, if it comes for you or someone other to choose the best
target, what criteria would you use? I hope, a technical review would be
the first criteria.
Regarding tests. Definitely, it is a very attractive idea to have an
ultimate test or a set of tests to just run them and everything becomes
obvious. But, unfortunately, you know, effort to implement such tests is
comparable with effort to implement the features those tests are
testing. But, on my side, I'm willing to run any test you like.
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.
Small correction (although it doesn't matter):
- The pass through architecture of STGT isn't unusable, it only
doesn't implement all it is needed for correct SCSI-confirming way to
provide 1 to many relationship and fundamentally can't do that
effectively for simultaneous remote and local access from the target via
sg/st/etc.
- The ABI (architecture, actually, which it serves) is flawed in the
performance side, because it doesn't allow to achieve better performance
than it currently has.
I'm sure STGT appreciates the frank assessments, but it doesn't seem to
merit too many "plays well with others" points.
I agree with you, but if you were me, what would you do? You know how
STGT was started. At that time SCST already was in a good shape with a
users base. But after private SCST evaluation completely behind my back
based on misunderstandings and incorrect assumptions STGT was invented
by the STGT developers. Nobody asked me anything. If at that time I had
been asked to clarify the tasks SCST is solving and why it is solving
them the chosen ways, it would have saved a lot for the Linux community.
Then my critics of the chosen approach have just been ignored. So, from
my POV it rather looks like it is STGT developers who don't want "play
well with me". And the current situation with the SCSI target agreement
behind our back only supports that. So, could you advice how we can go
away from the current situation?
I have always open for cooperation. If I wrong in my critics (which is
always constructive, BTW) I welcome everyone to disagree with me and
tell me where I'm wrong.
(English isn't my native language, so sometimes I may be not quite
emotionally correct and sorry if I unintentionally offended somebody in
the past or could offend in the future.)
Thanks,
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
