From: Vladislav Bolkhovitin <vst@vlnb.net>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Chris Weiss <cweiss@gmail.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
scst-devel <scst-devel@lists.sourceforge.net>,
iscsitarget-devel@lists.sourceforge.net, stgt@vger.kernel.org,
James Bottomley <James.Bottomley@hansenpartnership.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
Mike Christie <michaelc@cs.wisc.edu>,
Ross Walker <rswwalker@gmail.com>
Subject: Re: [Scst-devel] [ANNOUNCE]: Comparison of features between different SCSI targets (SCST, STGT, IET, LIO) updated
Date: Tue, 07 Sep 2010 01:51:10 +0400 [thread overview]
Message-ID: <4C85624E.3090404@vlnb.net> (raw)
In-Reply-To: <1283458331.5598.129.camel@haakon2.linux-iscsi.org>
Nicholas A. Bellinger, on 09/03/2010 12:12 AM wrote:
>>> I updated the Linux SCSI targets comparison page
>>> http://scst.sourceforge.net/comparison.html, which compares features of
>>> the existing Linux SCSI target subsystems. The comparison includes SCST,
>>> STGT, IET and LIO. I added IET there, because it is the most used Linux
>>> iSCSI target at the moment.
>> .
>> .
>>>
>>> If you see I'm wrong somewhere or forgot something, you are welcome to
>>> correct me and I will fix that.
>>>
>>> Vlad
>>>
>>
>> as a user following the potential inclusion of a kernel-space target,
>> iscsi specifically, I would be very interested in seeing what other
>> pluses the other frameworks have over scst, because if this chart is
>> accurate, all the other targets have quite a ways to go to catch up.
>>
>
> Actually sorry, anyone who has spent more than 30 minutes looking at the
> TCM v4 code that has already been posted to linux-scsi on monday knows
> this list just more handwaving. I suggest you start doing the same
> (actually discussion specific source file + line refrences) unless you
> actually want to trust this hopelessly out-of-date list on blind
> princaple.
Well, I expected your reaction like that. You have nothing to say, so
(as usually) prefer to call all "handwaving" and pretend it doesn't exist.
>> To me, lacking correct reserve and task management means "not ready
>> for public consumption". Making any kernel change that does not have
>> RESERVE/RELEASE and full TM command support is only going to make
>> Linux look buggy and amateur-ish in the storage world.
>
> First, understand that Vlad has been asked to produce a problem use case
> for his CRH=1 (Compatibility Reservation Handling) concerns using the
> SPC-3 RESERVE/RELEASE methods with the TCM v4 code.
For what is CRH here? It has no relation to the problem.
> He has been never
> been able to produce a use case, ever.
I did it at least twice and can do again if somebody ask. I'd suggest
you to check this list archive. After that STGT and IET teams fixed that
problem in their implementations.
> Also, just for reference, does
> SCST's SPC-3 persisent reservation handling actually properly support
> CRH=1 emulation from spc4r17..? Last time I checked, it most certainly
> did *not*.
It does. I'd suggest to check again, starting from scst_reserve_local().
> Second, in terms of TM emulation / passthrough support in the TCM v4
> code, we follow what is implemented in drivers/scsi ML and LLDs,
> primarly to properly for Linux SCSI Initiators. I honestly don't have
> alot of interesting currently in implementing all of the ancient TM
> emulation that none of the mainline SCSI LLDs in Linux implement today,
> or plan to do the future. As for specific TM concerns, I am happy to
> address then on a case by case basis with the appropiate use case.
Interesting, from which times ABORT TASK is ancient?
Vlad
prev parent reply other threads:[~2010-09-06 21:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-02 19:31 [ANNOUNCE]: Comparison of features between different SCSI targets (SCST, STGT, IET, LIO) updated Vladislav Bolkhovitin
2010-09-02 20:00 ` [Scst-devel] " Chris Weiss
2010-09-02 20:12 ` Nicholas A. Bellinger
2010-09-02 20:50 ` Chris Weiss
2010-09-02 21:31 ` Nicholas A. Bellinger
2010-09-06 21:51 ` Vladislav Bolkhovitin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C85624E.3090404@vlnb.net \
--to=vst@vlnb.net \
--cc=James.Bottomley@hansenpartnership.com \
--cc=cweiss@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=iscsitarget-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=nab@linux-iscsi.org \
--cc=rswwalker@gmail.com \
--cc=scst-devel@lists.sourceforge.net \
--cc=stgt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox