Hello James and others,
--- On Tue, 8/17/10, James Bottomley <[email protected]> wrote:
> From: James Bottomley <[email protected]>
> Subject: Re: [Scst-devel] Fwd: Re:? linuxcon 2010...
> To: "Vladislav Bolkhovitin" <[email protected]>
> Cc: "scst-devel" <[email protected]>, [email protected], [email protected]
> Date: Tuesday, August 17, 2010, 8:30 PM
> On Mon, 2010-08-16 at 20:20 +0400,
> Vladislav Bolkhovitin wrote:
> > Hello James,
> >
> > Could you comment rumors that decision about future
> Linux SCSI target
> > subsystem is done as well as other related rumors:
>
> If this is related to LSF, the notes on the I/O track are
> here:
>
> http://lwn.net/Articles/400491/
During the open panel, my question was really specific -
Q) What is the future of a SCSI-target subsystem in linux. Which
???target engine/subsystem can we expect?
Your answer) There is place for only 1 target-subsystem in the Linux scsi stack and in the LSF summit the decision was taken to merge LIO. Has that
decision changed since the summit?
As a scst-user what I would like to understand is, what was that decision based on? Because the LSF summit was 'small by invitation' only summit. The notes don't give us an insight on the selection criteria/merits etc.
>
> > 3. I have heard you said "Vlad wasn't comfortable in
> handing up the
> > control to the maintainers ... (this is how kernel.org
> works)." I have
> > no idea what you meant. I have never been asked about
> anything like
> > that, so I couldn't say anyhow that I'm not
> comfortable with anything.
> > Could you clarify that?
> >
3) above is something that I emailed Vlad and the scst community based on our offline conversation after the open panel. If SCST really has licensing issues then I will personally stop using SCST. Since Vlad hasn't
expressed any concerns on the above and neither have you commented on it, is it safe to assume that the licensing requirement is a non-issue?
Chetan Loke
On Wed, 2010-08-18 at 07:58 -0700, Chetan Loke wrote:
> Hello James and others,
>
> --- On Tue, 8/17/10, James Bottomley <[email protected]> wrote:
>
> > From: James Bottomley <[email protected]>
> > Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...
> > To: "Vladislav Bolkhovitin" <[email protected]>
> > Cc: "scst-devel" <[email protected]>, [email protected], [email protected]
> > Date: Tuesday, August 17, 2010, 8:30 PM
> > On Mon, 2010-08-16 at 20:20 +0400,
> > Vladislav Bolkhovitin wrote:
> > > Hello James,
> > >
> > > Could you comment rumors that decision about future
> > Linux SCSI target
> > > subsystem is done as well as other related rumors:
> >
> > If this is related to LSF, the notes on the I/O track are
> > here:
> >
> > http://lwn.net/Articles/400491/
>
>
> During the open panel, my question was really specific -
>
> Q) What is the future of a SCSI-target subsystem in linux. Which
> target engine/subsystem can we expect?
>
> Your answer) There is place for only 1 target-subsystem in the Linux
> scsi stack and in the LSF summit the decision was taken to merge LIO.
> Has that
> decision changed since the summit?
The decision hasn't been taken to merge LIO, but based on what happened
at the summit, I think it's the most viable candidate and will likely be
merged by 2.6.37
> As a scst-user what I would like to understand is, what was that
> decision based on? Because the LSF summit was 'small by invitation'
> only summit. The notes don't give us an insight on the selection
> criteria/merits etc.
The notes list 3, what's unclear about it?
>
> >
> > > 3. I have heard you said "Vlad wasn't comfortable in
> > handing up the
> > > control to the maintainers ... (this is how kernel.org
> > works)." I have
> > > no idea what you meant. I have never been asked about
> > anything like
> > > that, so I couldn't say anyhow that I'm not
> > comfortable with anything.
> > > Could you clarify that?
> > >
>
> 3) above is something that I emailed Vlad and the scst community based
> on our offline conversation after the open panel. If SCST really has
> licensing issues then I will personally stop using SCST. Since Vlad
> hasn't
> expressed any concerns on the above and neither have you commented on
> it, is it safe to assume that the licensing requirement is a
> non-issue?
No.
James
Ok, pls ignore my first question:
I was trying to access https://lwn.net/Articles/399148/
But I just read:
http://lwn.net/Articles/400589/
Chetan
--- On Wed, 8/18/10, Chetan Loke <[email protected]> wrote:
> From: Chetan Loke <[email protected]>
> Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...
> To: "Vladislav Bolkhovitin" <[email protected]>, "James Bottomley" <[email protected]>
> Cc: "scst-devel" <[email protected]>, [email protected], [email protected]
> Date: Wednesday, August 18, 2010, 2:58 PM
> Hello James and others,
>
> --- On Tue, 8/17/10, James Bottomley <[email protected]>
> wrote:
>
> > From: James Bottomley <[email protected]>
> > Subject: Re: [Scst-devel] Fwd: Re:? linuxcon 2010...
> > To: "Vladislav Bolkhovitin" <[email protected]>
> > Cc: "scst-devel" <[email protected]>,
> [email protected],
> [email protected]
> > Date: Tuesday, August 17, 2010, 8:30 PM
> > On Mon, 2010-08-16 at 20:20 +0400,
> > Vladislav Bolkhovitin wrote:
> > > Hello James,
> > >
> > > Could you comment rumors that decision about
> future
> > Linux SCSI target
> > > subsystem is done as well as other related
> rumors:
> >
> > If this is related to LSF, the notes on the I/O track
> are
> > here:
> >
> > http://lwn.net/Articles/400491/
>
>
> During the open panel, my question was really specific -
>
> Q) What is the future of a SCSI-target subsystem in linux.
> Which
> ???target engine/subsystem can we expect?
>
> Your answer) There is place for only 1 target-subsystem in
> the Linux scsi stack and in the LSF summit the decision was
> taken to merge LIO. Has that
> decision changed since the summit?
>
> As a scst-user what I would like to understand is, what was
> that decision based on? Because the LSF summit was 'small by
> invitation' only summit. The notes don't give us an insight
> on the selection criteria/merits etc.
>
>
> >
> > > 3. I have heard you said "Vlad wasn't comfortable
> in
> > handing up the
> > > control to the maintainers ... (this is how
> kernel.org
> > works)." I have
> > > no idea what you meant. I have never been asked
> about
> > anything like
> > > that, so I couldn't say anyhow that I'm not
> > comfortable with anything.
> > > Could you clarify that?
> > >
>
> 3) above is something that I emailed Vlad and the scst
> community based on our offline conversation after the open
> panel. If SCST really has licensing issues then I will
> personally stop using SCST. Since Vlad hasn't
> expressed any concerns on the above and neither have you
> commented on it, is it safe to assume that the licensing
> requirement is a non-issue?
>
>
> Chetan Loke
>
>
>
> ? ? ?
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Scst-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/scst-devel
>
On Wed, Aug 18, 2010 at 11:11 AM, James Bottomley
<[email protected]> wrote:
> The decision hasn't been taken to merge LIO, but based on what happened
> at the summit, I think it's the most viable candidate and will likely be
> merged by 2.6.37
>
During the open panel, facebook guys and others were tooting that
start-ups thrive because they can hack linux. Well there are quite a
few start-ups that use scst too for creating target appliances.
Has anyone even bothered to glance the scst mailing list to see if
that community is dead or alive?
I for one use scst to create synthetic work-loads and test 200+ VM
nodes in an ESX cluster. Anyone who has worked on a SAN OS will
appreciate the simplicity of SCST. And if folks still can't understand
the SCST code(after reading the README) then they are still welcome to
send an email on SCST. Would you like to make your FC stack go faster,
well please drop us an email on SCST and we will try our best to
further optimize the FC driver.
I know folks who don't understand simple DMA bus traces, FC wire
traces and yet they have the power to influence decisions.
James you are an expert but not everyone is. This is not a venting
session but even folks who are new to target architecture find it easy
to hack SCST.
>> As a scst-user what I would like to understand is, what was that
>> decision based on? Because the LSF summit was 'small by invitation'
>> only summit. The notes don't give us an insight on the selection
>> criteria/merits etc.
>
> The notes list 3, what's unclear about it?
Sorry, my bad. I sent an email earlier. I was trying to access a different link.
>> > > 3. I have heard you said "Vlad wasn't comfortable in
>> > handing up the
>> > > control to the maintainers ... (this is how kernel.org
>> > works)." I have
>> > > no idea what you meant. I have never been asked about
>> > anything like
>> > > that, so I couldn't say anyhow that I'm not
>> > comfortable with anything.
>> > > Could you clarify that?
>> > >
>>
>> 3) above is something that I emailed Vlad and the scst community based
>> on our offline conversation after the open panel. If SCST really has
>> licensing issues then I will personally stop using SCST. Since Vlad
>> hasn't
>> expressed any concerns on the above and neither have you commented on
>> it, is it safe to assume that the licensing requirement is a
>> non-issue?
>
> No.
>
huh? It's dual licensed. GPL and BSD(if I'm not wrong).
> James
--cloke
On Wed, 2010-08-18 at 12:04 -0400, Chetan Loke wrote:
> On Wed, Aug 18, 2010 at 11:11 AM, James Bottomley
> <[email protected]> wrote:
> > The decision hasn't been taken to merge LIO, but based on what happened
> > at the summit, I think it's the most viable candidate and will likely be
> > merged by 2.6.37
> >
>
> During the open panel, facebook guys and others were tooting that
> start-ups thrive because they can hack linux. Well there are quite a
> few start-ups that use scst too for creating target appliances.
> Has anyone even bothered to glance the scst mailing list to see if
> that community is dead or alive?
>
> I for one use scst to create synthetic work-loads and test 200+ VM
> nodes in an ESX cluster. Anyone who has worked on a SAN OS will
> appreciate the simplicity of SCST. And if folks still can't understand
> the SCST code(after reading the README) then they are still welcome to
> send an email on SCST. Would you like to make your FC stack go faster,
> well please drop us an email on SCST and we will try our best to
> further optimize the FC driver.
>
> I know folks who don't understand simple DMA bus traces, FC wire
> traces and yet they have the power to influence decisions.
>
> James you are an expert but not everyone is. This is not a venting
> session but even folks who are new to target architecture find it easy
> to hack SCST.
But that's not really relevant, is it? I would expect that whatever I
do, even keeping both out of tree, the communities around the solutions
would still exist and be vibrant, since they're out of tree now, nothing
will have changed.
James
On Wed, Aug 18, 2010 at 5:11 PM, James Bottomley
<[email protected]> wrote:
> On Wed, 2010-08-18 at 07:58 -0700, Chetan Loke wrote:
>> Hello James and others,
>>
>> --- On Tue, 8/17/10, James Bottomley <[email protected]> wrote:
>>
>> > From: James Bottomley <[email protected]>
>> > Subject: Re: [Scst-devel] Fwd: Re: ?linuxcon 2010...
>> > To: "Vladislav Bolkhovitin" <[email protected]>
>> > Cc: "scst-devel" <[email protected]>, [email protected], [email protected]
>> > Date: Tuesday, August 17, 2010, 8:30 PM
>> > On Mon, 2010-08-16 at 20:20 +0400,
>> > Vladislav Bolkhovitin wrote:
>> > > Hello James,
>> > >
>> > > Could you comment rumors that decision about future
>> > Linux SCSI target
>> > > subsystem is done as well as other related rumors:
>> >
>> > If this is related to LSF, the notes on the I/O track are
>> > here:
>> >
>> > http://lwn.net/Articles/400491/
>>
>>
>> During the open panel, my question was really specific -
>>
>> Q) What is the future of a SCSI-target subsystem in linux. Which
>> ? ?target engine/subsystem can we expect?
>>
>> Your answer) There is place for only 1 target-subsystem in the Linux
>> scsi stack and in the LSF summit the decision was taken to merge LIO.
>> Has that
>> decision changed since the summit?
>
> The decision hasn't been taken to merge LIO, but based on what happened
> at the summit, I think it's the most viable candidate and will likely be
> merged by 2.6.37
>
>> As a scst-user what I would like to understand is, what was that
>> decision based on? Because the LSF summit was 'small by invitation'
>> only summit. The notes don't give us an insight on the selection
>> criteria/merits etc.
>
> The notes list 3, what's unclear about it?
Hello James,
Thanks for taking notes during the storage track and sharing these
notes (http://lwn.net/Articles/400589/). These notes are interesting
but do not reveal why LIO is preferred.
Also, the list with the three acceptance criteria is incomplete. A
very important criterion before any kernel code can be merged upstream
is whether or not there is a maintainer for that code. Someone who has
proven prior kernel coding experience and someone who understands the
new code thoroughly.
Bart.
James Bottomley wrote:
>> During the open panel, my question was really specific -
>>
>> Q) What is the future of a SCSI-target subsystem in linux. Which
>> target engine/subsystem can we expect?
>>
>> Your answer) There is place for only 1 target-subsystem in the Linux
>> scsi stack and in the LSF summit the decision was taken to merge LIO.
>> Has that
>> decision changed since the summit?
>
> The decision hasn't been taken to merge LIO, but based on what happened
> at the summit, I think it's the most viable candidate and will likely be
> merged by 2.6.37
Quick question ... will LIO support SRP? I should probably run over to
their lists and ask, but a quick inspection of their site this morning
shows that they are mostly iSCSI and FC focused. (LIO folks, please
feel free to step up and comment)
I'd certainly like to see a single framework, but not at the cost of
losing important (to us) functionality. We'd like to continue to use
SRP, and iSCSI. We'd like to use iSER (which is in the tgt stack) which
LIO would give us when merged with tgt. We are currently using SCST's
iSCSI and SRP stack within our products.
I believe this also affects the OFED folks, as SRP is one of their
services (based upon SCST).
Any guidance (in a general sense on the target side, not necessarily
specific to LIO) on this would be appreciated. SCST has been a good
system for us to work with. I'd hate to lose its functionality, and
have us be forced to re-engineer some of our backend logic to work
around the missing bits. Thanks!
Regards,
Joe
--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: [email protected]
web : http://scalableinformatics.com
http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax : +1 866 888 3112
cell : +1 734 612 4615
James Bottomley, on 08/18/2010 08:18 PM wrote:
>> James you are an expert but not everyone is. This is not a venting
>> session but even folks who are new to target architecture find it easy
>> to hack SCST.
>
> But that's not really relevant, is it? I would expect that whatever I
> do, even keeping both out of tree, the communities around the solutions
> would still exist and be vibrant, since they're out of tree now, nothing
> will have changed.
The problem that people do believe that the merged code is the best
code, so the being merged is an immediate HUGE advertisement. So, you
can't say if a code is inside the mainline tree or not isn't relevant.
This is the source of the questions from the SCST community. SCST is at
the moment the best code. It's several years ahead any competitor. SCST
has more functionality, SCST has more users, SCST has bigger community,
SCST has more testing and, hence, stability, SCST has more support from
storage vendors, etc. But for some reasons all those suddenly ignored
and a raw, pursuing SCST code preferred instead.
So, we want to know those reasons. SCST wasn't even really considered.
Isn't Linux anymore a place where the best code wins? Frankly, it looks
like the decision was done under closed doors based on rather political
reasons, like personal connections...
Vlad
On Wed, Aug 18, 2010 at 12:18 PM, James Bottomley
<[email protected]> wrote:
> On Wed, 2010-08-18 at 12:04 -0400, Chetan Loke wrote:
>> On Wed, Aug 18, 2010 at 11:11 AM, James Bottomley
>> <[email protected]> wrote:
>> > The decision hasn't been taken to merge LIO, but based on what happened
>> > at the summit, I think it's the most viable candidate and will likely be
>> > merged by 2.6.37
>> >
>>
>> During the open panel, facebook guys and others were tooting that
>> start-ups thrive because they can hack linux. Well there are quite a
>> few start-ups that use scst too for creating target appliances.
>> Has anyone even bothered to glance the scst mailing list to see if
>> that community is dead or alive?
>>
>> I for one use scst to create synthetic work-loads and test 200+ VM
>> nodes in an ESX cluster. Anyone who has worked on a SAN OS will
>> appreciate the simplicity of SCST. And if folks still can't understand
>> the SCST code(after reading the README) then they are still welcome to
>> send an email on SCST. Would you like to make your FC stack go faster,
>> well please drop us an email on SCST and we will try our best to
>> further optimize the FC driver.
>>
>> I know folks who don't understand simple DMA bus traces, FC wire
>> traces and yet they have the power to influence decisions.
>>
>> James you are an expert but not everyone is. This is not a venting
>> session but even folks who are new to target architecture find it easy
>> to hack SCST.
>
> But that's not really relevant, is it? I would expect that whatever I
> do, even keeping both out of tree, the communities around the solutions
> would still exist and be vibrant, since they're out of tree now, nothing
> will have changed.
>
Of course it's relevant. Not all engineers know about everything when
they venture in a new area. SCST overcomes that. It's not
intimidating. Infact, 3 months back, I asked a storport/miniport(aka
Windows) guy to take a look at scst and after studying the README he
was amazed to see how easy it was. Plus,everyone knows that if a
solution is inbox then it's just easier to maintain. Also no need to
patch/re-spin my iso. And you are missing the point - find me one good
technical conversation thread on LIO! What does that tell you? Why not
give a chance(or atleast consider?) to someone who has a wide/active
user base?
LIO never struggled to push their code upstream and it still is a
viable candidate? On the other hand scst users/developers are ready to
bend over to accommodate all the changes! What does that tell you?
James, how can a community remain vibrant when one solution is
favoured over another w/o any clear explanation and justification?
It's like the old saying - the lips are moving but all I hear is blah
blah blah. We look up to you but why should we accept the outcome of a
closed door LSF session ;)?
> James
-- cloke
Chetan Loke, on 08/18/2010 06:58 PM wrote:
> 3) above is something that I emailed Vlad and the scst community
> based on our offline conversation after the open panel. If SCST
> really has licensing issues then I will personally stop using SCST.
> Since Vlad hasn't expressed any concerns on the above and neither
> have you commented on it, is it safe to assume that the licensing
> requirement is a non-issue?
I believe there are no licensing issues with SCST. All the patches I
have submitted and going to submit licensed under GPLv2.
Vlad
Joe Landman, on 08/18/2010 08:28 PM wrote:
> Quick question ... will LIO support SRP? I should probably run over to
> their lists and ask, but a quick inspection of their site this morning
> shows that they are mostly iSCSI and FC focused. (LIO folks, please
> feel free to step up and comment)
>
> I'd certainly like to see a single framework, but not at the cost of
> losing important (to us) functionality. We'd like to continue to use
> SRP, and iSCSI. We'd like to use iSER (which is in the tgt stack) which
> LIO would give us when merged with tgt. We are currently using SCST's
> iSCSI and SRP stack within our products.
Joe,
For iSER LIO would not give you anything SCST can't give you. With LIO
you would use the iSER target via STGT pass-through sg/bsg. You can the
same way use it with SCST scst_local module.
Vlad
James Bottomley, on 08/18/2010 08:18 PM wrote:
>> James you are an expert but not everyone is. This is not a venting
>> session but even folks who are new to target architecture find it easy
>> to hack SCST.
>
> But that's not really relevant, is it? I would expect that whatever I
> do, even keeping both out of tree, the communities around the solutions
> would still exist and be vibrant, since they're out of tree now, nothing
> will have changed.
The problem that people do believe that the merged code is the best
code, so the being merged is an immediate HUGE advertisement. So, you
can't say if a code is inside the mainline tree or not isn't relevant.
This is the source of the questions from the SCST community. SCST is at
the moment the best code. It's several years ahead any competitor. SCST
has more functionality, SCST has more users, SCST has bigger community,
SCST has more testing and, hence, stability, SCST has more support from
storage vendors, etc. But for some reasons all those suddenly ignored
and a raw, pursuing SCST code preferred instead.
So, we want to know those reasons. SCST wasn't even really considered.
Isn't Linux anymore a place where the best code wins? Frankly, it looks
like the decision was done under closed doors based on rather political
reasons, like personal connections...
Vlad
[Jack]Vote for SCST as a user and target driver developer based on SCST.
SCST really do good job.
On Thursday 19 August 2010 at 03:18 (CET), jack wang wrote:
> [Jack]Vote for SCST as a user and target driver developer based on SCST.
> SCST really do good job.
+1 from a happy SCST end-user.
Regards,
Ruben Laban
Senior Network and Systems Administrator
ISM eCompany