Hello James,
Could you comment rumors that decision about future Linux SCSI target
subsystem is done as well as other related rumors:
1. What don't you like in the transition path for users from STGT to
SCST, which I proposed:
- The only people which would be affected by replacing of STGT by SCST
would be users of ibmvstgt. Other STGT users would not notice it at all.
Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
the update for its users would be just writing of a simple scstadmin's
config file.
- STGT doesn't have backend drivers, which SCST doesn't have, so
there's nothing to worry here. At max, AIO support should be added to
fileio_tgt.
- STGT user space targets can use SCST backend via scst_local module.
Scst_local module is ready and work very well.
The result would be very clear without any obsolete mess.
2. Don't you like something in the sysfs interface SCST has?
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?
4. Have you changed your opinion that a driver level multipath is
forbidden in Linux and now you think that an iSCSI target with MC/S
support is acceptable?
Thanks,
Vlad
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/
> 1. What don't you like in the transition path for users from STGT to
> SCST, which I proposed:
>
> - The only people which would be affected by replacing of STGT by SCST
> would be users of ibmvstgt. Other STGT users would not notice it at all.
> Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
> the update for its users would be just writing of a simple scstadmin's
> config file.
>
> - STGT doesn't have backend drivers, which SCST doesn't have, so
> there's nothing to worry here. At max, AIO support should be added to
> fileio_tgt.
>
> - STGT user space targets can use SCST backend via scst_local module.
> Scst_local module is ready and work very well.
>
> The result would be very clear without any obsolete mess.
So does that get us up to being a drop in replacement? I think you're
saying that even with all of this, at least the VSCSI part will need
updating, so the answer seems to be "no".
> 2. Don't you like something in the sysfs interface SCST has?
I don't think so ... from a cursory glance it looks functional.
> 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?
>
> 4. Have you changed your opinion that a driver level multipath is
> forbidden in Linux and now you think that an iSCSI target with MC/S
> support is acceptable?
no; I still think MCS is a pointless duplication of multipath that only
works for iSCSI.
James
James Bottomley, on 08/18/2010 12:30 AM wrote:
>> 1. What don't you like in the transition path for users from STGT to
>> SCST, which I proposed:
>>
>> - The only people which would be affected by replacing of STGT by SCST
>> would be users of ibmvstgt. Other STGT users would not notice it at all.
>> Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
>> the update for its users would be just writing of a simple scstadmin's
>> config file.
>>
>> - STGT doesn't have backend drivers, which SCST doesn't have, so
>> there's nothing to worry here. At max, AIO support should be added to
>> fileio_tgt.
>>
>> - STGT user space targets can use SCST backend via scst_local module.
>> Scst_local module is ready and work very well.
>>
>> The result would be very clear without any obsolete mess.
>
> So does that get us up to being a drop in replacement? I think you're
> saying that even with all of this, at least the VSCSI part will need
> updating, so the answer seems to be "no".
Sorry, I can't understand, "no" for which? For the whole transition
path, or just until there is a patch for ibmvstgt to become ibmvscst?
>> 4. Have you changed your opinion that a driver level multipath is
>> forbidden in Linux and now you think that an iSCSI target with MC/S
>> support is acceptable?
>
> no; I still think MCS is a pointless duplication of multipath that only
> works for iSCSI.
Then, does it mean that similarly as it was with open-iscsi, which had
to remove MC/S support to be able to be accepted into the mainline, an
iSCSI target can't go into mainline if it has MC/S?
Thanks for answers,
Vlad
On Wed, 2010-08-18 at 21:52 +0400, Vladislav Bolkhovitin wrote:
> James Bottomley, on 08/18/2010 12:30 AM wrote:
> >> 1. What don't you like in the transition path for users from STGT to
> >> SCST, which I proposed:
> >>
> >> - The only people which would be affected by replacing of STGT by SCST
> >> would be users of ibmvstgt. Other STGT users would not notice it at all.
> >> Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
> >> the update for its users would be just writing of a simple scstadmin's
> >> config file.
> >>
> >> - STGT doesn't have backend drivers, which SCST doesn't have, so
> >> there's nothing to worry here. At max, AIO support should be added to
> >> fileio_tgt.
> >>
> >> - STGT user space targets can use SCST backend via scst_local module.
> >> Scst_local module is ready and work very well.
> >>
> >> The result would be very clear without any obsolete mess.
> >
> > So does that get us up to being a drop in replacement? I think you're
> > saying that even with all of this, at least the VSCSI part will need
> > updating, so the answer seems to be "no".
>
> Sorry, I can't understand, "no" for which? For the whole transition
> path, or just until there is a patch for ibmvstgt to become ibmvscst?
No to the question "does that get us up to being a drop in replacement
[for STGT]?"
> >> 4. Have you changed your opinion that a driver level multipath is
> >> forbidden in Linux and now you think that an iSCSI target with MC/S
> >> support is acceptable?
> >
> > no; I still think MCS is a pointless duplication of multipath that only
> > works for iSCSI.
>
> Then, does it mean that similarly as it was with open-iscsi, which had
> to remove MC/S support to be able to be accepted into the mainline, an
> iSCSI target can't go into mainline if it has MC/S?
To be honest, I don't care about targets. I only care that the
initiators do the right thing.
James
James Bottomley, on 08/19/2010 12:43 AM wrote:
>>>> 1. What don't you like in the transition path for users from STGT to
>>>> SCST, which I proposed:
>>>>
>>>> - The only people which would be affected by replacing of STGT by SCST
>>>> would be users of ibmvstgt. Other STGT users would not notice it at all.
>>>> Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
>>>> the update for its users would be just writing of a simple scstadmin's
>>>> config file.
>>>>
>>>> - STGT doesn't have backend drivers, which SCST doesn't have, so
>>>> there's nothing to worry here. At max, AIO support should be added to
>>>> fileio_tgt.
>>>>
>>>> - STGT user space targets can use SCST backend via scst_local module.
>>>> Scst_local module is ready and work very well.
>>>>
>>>> The result would be very clear without any obsolete mess.
>>>
>>> So does that get us up to being a drop in replacement? I think you're
>>> saying that even with all of this, at least the VSCSI part will need
>>> updating, so the answer seems to be "no".
>>
>> Sorry, I can't understand, "no" for which? For the whole transition
>> path, or just until there is a patch for ibmvstgt to become ibmvscst?
>
> No to the question "does that get us up to being a drop in replacement
> [for STGT]?"
I'm sorry again, I did my best, but still can't understand. What you
wrote looks for me too ambiguous. My English must be too bad..
Could elaborate more for what the "no" is, please? What don't you like
in the plan I suggested?
>>>> 4. Have you changed your opinion that a driver level multipath is
>>>> forbidden in Linux and now you think that an iSCSI target with MC/S
>>>> support is acceptable?
>>>
>>> no; I still think MCS is a pointless duplication of multipath that only
>>> works for iSCSI.
>>
>> Then, does it mean that similarly as it was with open-iscsi, which had
>> to remove MC/S support to be able to be accepted into the mainline, an
>> iSCSI target can't go into mainline if it has MC/S?
>
> To be honest, I don't care about targets. I only care that the
> initiators do the right thing.
Isn't it quite illogical? You are forbidding a facility on one side of
the link and allow it on another?
Thanks,
Vlad
On Sat, 2010-08-21 at 22:51 +0400, Vladislav Bolkhovitin wrote:
> James Bottomley, on 08/19/2010 12:43 AM wrote:
> >>>> 1. What don't you like in the transition path for users from STGT to
> >>>> SCST, which I proposed:
> >>>>
> >>>> - The only people which would be affected by replacing of STGT by SCST
> >>>> would be users of ibmvstgt. Other STGT users would not notice it at all.
> >>>> Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
> >>>> the update for its users would be just writing of a simple scstadmin's
> >>>> config file.
> >>>>
> >>>> - STGT doesn't have backend drivers, which SCST doesn't have, so
> >>>> there's nothing to worry here. At max, AIO support should be added to
> >>>> fileio_tgt.
> >>>>
> >>>> - STGT user space targets can use SCST backend via scst_local module.
> >>>> Scst_local module is ready and work very well.
> >>>>
> >>>> The result would be very clear without any obsolete mess.
> >>>
> >>> So does that get us up to being a drop in replacement? I think you're
> >>> saying that even with all of this, at least the VSCSI part will need
> >>> updating, so the answer seems to be "no".
> >>
> >> Sorry, I can't understand, "no" for which? For the whole transition
> >> path, or just until there is a patch for ibmvstgt to become ibmvscst?
> >
> > No to the question "does that get us up to being a drop in replacement
> > [for STGT]?"
>
> I'm sorry again, I did my best, but still can't understand. What you
> wrote looks for me too ambiguous. My English must be too bad..
>
> Could elaborate more for what the "no" is, please? What don't you like
> in the plan I suggested?
No it isn't a plan that gives us a drop in replacement for STGT. I
didn't say migration path to random userspace target, I said reuse of
existing code.
James
On Sat, Aug 21, 2010 at 4:38 PM, James Bottomley
<[email protected]> wrote:
> On Sat, 2010-08-21 at 22:51 +0400, Vladislav Bolkhovitin wrote:
>> James Bottomley, on 08/19/2010 12:43 AM wrote:
>> >>>> 1. What don't you like in the transition path for users from STGT to
>> >>>> SCST, which I proposed:
>> >>>>
>> >>>> ? ? - The only people which would be affected by replacing of STGT by SCST
>> >>>> would be users of ibmvstgt. Other STGT users would not notice it at all.
>> >>>> Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
>> >>>> the update for its users would be just writing of a simple scstadmin's
>> >>>> config file.
>> >>>>
>> >>>> ? ? - STGT doesn't have backend drivers, which SCST doesn't have, so
>> >>>> there's nothing to worry here. At max, AIO support should be added to
>> >>>> fileio_tgt.
>> >>>>
>> >>>> ? ? - STGT user space targets can use SCST backend via scst_local module.
>> >>>> Scst_local module is ready and work very well.
>> >>>>
>> >>>> The result would be very clear without any obsolete mess.
>> >>>
>> >>> So does that get us up to being a drop in replacement? ?I think you're
>> >>> saying that even with all of this, at least the VSCSI part will need
>> >>> updating, so the answer seems to be "no".
>> >>
>> >> Sorry, I can't understand, "no" for which? For the whole transition
>> >> path, or just until there is a patch for ibmvstgt to become ibmvscst?
>> >
>> > No to the question "does that get us up to being a drop in replacement
>> > [for STGT]?"
>>
>> I'm sorry again, I did my best, but still can't understand. What you
>> wrote looks for me too ambiguous. My English must be too bad..
>>
>> Could elaborate more for what the "no" is, please? What don't you like
>> in the plan I suggested?
>
> No it isn't a plan that gives us a drop in replacement for STGT. ?I
> didn't say migration path to random userspace target, I said reuse of
> existing code.
Hi James,
(disclaimer: I'm a hoi polloi SCST user)
I'm not sure if I understand why there is a need for a replacement
target to reuse existing code, and would definitely appreciate a brief
explanation or a pointer to an earlier one. But even that aside, I'm
curious if the criteria for what a replacement target must have for
(at least potential) inclusion into the kernel were ever clearly
outlined in the past. If they were, then there probably would have
been things like interested contenders, deadlines, feature
comparisons, code reviews, and so on, right?
Now, I can't claim familiarity with the kernel development process, or
any "political" workings in it. The aforementioned however would seem
like a logical way of doing this since I assume that for whatever
reason, there is a strict limit to only one generic SCSI target in the
Linux kernel, and obviously as per this thread the current one is
being replaced.
Please correct/rebuke me as needed :)
Thanks,
-Gennadiy
On Sun, 2010-08-22 at 18:10 -0400, Gennadiy Nerubayev wrote:
> On Sat, Aug 21, 2010 at 4:38 PM, James Bottomley
> <[email protected]> wrote:
> > On Sat, 2010-08-21 at 22:51 +0400, Vladislav Bolkhovitin wrote:
> >> James Bottomley, on 08/19/2010 12:43 AM wrote:
> >> >>>> 1. What don't you like in the transition path for users from STGT to
> >> >>>> SCST, which I proposed:
> >> >>>>
> >> >>>> - The only people which would be affected by replacing of STGT by SCST
> >> >>>> would be users of ibmvstgt. Other STGT users would not notice it at all.
> >> >>>> Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
> >> >>>> the update for its users would be just writing of a simple scstadmin's
> >> >>>> config file.
> >> >>>>
> >> >>>> - STGT doesn't have backend drivers, which SCST doesn't have, so
> >> >>>> there's nothing to worry here. At max, AIO support should be added to
> >> >>>> fileio_tgt.
> >> >>>>
> >> >>>> - STGT user space targets can use SCST backend via scst_local module.
> >> >>>> Scst_local module is ready and work very well.
> >> >>>>
> >> >>>> The result would be very clear without any obsolete mess.
> >> >>>
> >> >>> So does that get us up to being a drop in replacement? I think you're
> >> >>> saying that even with all of this, at least the VSCSI part will need
> >> >>> updating, so the answer seems to be "no".
> >> >>
> >> >> Sorry, I can't understand, "no" for which? For the whole transition
> >> >> path, or just until there is a patch for ibmvstgt to become ibmvscst?
> >> >
> >> > No to the question "does that get us up to being a drop in replacement
> >> > [for STGT]?"
> >>
> >> I'm sorry again, I did my best, but still can't understand. What you
> >> wrote looks for me too ambiguous. My English must be too bad..
> >>
> >> Could elaborate more for what the "no" is, please? What don't you like
> >> in the plan I suggested?
> >
> > No it isn't a plan that gives us a drop in replacement for STGT. I
> > didn't say migration path to random userspace target, I said reuse of
> > existing code.
>
> Hi James,
>
> (disclaimer: I'm a hoi polloi SCST user)
>
> I'm not sure if I understand why there is a need for a replacement
> target to reuse existing code, and would definitely appreciate a brief
> explanation or a pointer to an earlier one.
The best thread on the topic is this massive one:
http://marc.info/?t=120109820100005
I want replacement because evidence suggests that multiple things doing
the same thing don't get as much attention as a single one. We need to
support STGT because it's the one that has the in-kernel user base.
Just breaking them constitutes an ABI problem under the new kernel
rules.
> But even that aside, I'm
> curious if the criteria for what a replacement target must have for
> (at least potential) inclusion into the kernel were ever clearly
> outlined in the past. If they were, then there probably would have
> been things like interested contenders, deadlines, feature
> comparisons, code reviews, and so on, right?
Yes, in that thread.
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). If the two communities can't
work together (as seems to be the case) and I have to choose one, I'll
go by what helps me which, as I've said before, are:
1. That it would be a drop in replacement for STGT (our current
in-kernel target mode driver), since he only wanted a single
SCSI target infrastructure.
2. That it used a modern sysfs based control and configuration
plane.
3. That the code was reviewed as clean enough for inclusion.
> Now, I can't claim familiarity with the kernel development process, or
> any "political" workings in it. The aforementioned however would seem
> like a logical way of doing this since I assume that for whatever
> reason, there is a strict limit to only one generic SCSI target in the
> Linux kernel, and obviously as per this thread the current one is
> being replaced.
Well, my preference would be to keep STGT. However, I indicated to both
target infrastructures that if they could satisfy the above, I'd be OK
with replacing STGT, so I'm not about to go back on that after causing
quite a large amount of work.
James
On Mon, Aug 23, 2010 at 6:59 PM, James Bottomley
<[email protected]> wrote:
>
> On Sun, 2010-08-22 at 18:10 -0400, Gennadiy Nerubayev wrote:
> > [ ... ]
> > Hi James,
> >
> > (disclaimer: I'm a hoi polloi SCST user)
> >
> > I'm not sure if I understand why there is a need for a replacement
> > target to reuse existing code, and would definitely appreciate a brief
> > explanation or a pointer to an earlier one.
>
> The best thread on the topic is this massive one:
>
> http://marc.info/?t=120109820100005
>
> I want replacement because evidence suggests that multiple things doing
> the same thing don't get as much attention as a single one. ?We need to
> support STGT because it's the one that has the in-kernel user base.
> Just breaking them constitutes an ABI problem under the new kernel
> rules.
>
> > But even that aside, I'm
> > curious if the criteria for what a replacement target must have for
> > (at least potential) inclusion into the kernel were ever clearly
> > outlined in the past. If they were, then there probably would have
> > been things like interested contenders, deadlines, feature
> > comparisons, code reviews, and so on, right?
>
> Yes, in that thread.
>
> 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). ?If the two communities can't
> work together (as seems to be the case) and I have to choose one, I'll
> go by what helps me which, as I've said before, are:
>
> ? ? 1. That it would be a drop in replacement for STGT (our current
> ? ? ? ?in-kernel target mode driver), since he only wanted a single
> ? ? ? ?SCSI target infrastructure.
>
> ? ? 2. That it used a modern sysfs based control and configuration
> ? ? ? ?plane.
>
> ? ? 3. That the code was reviewed as clean enough for inclusion.
>
>
> > Now, I can't claim familiarity with the kernel development process, or
> > any "political" workings in it. The aforementioned however would seem
> > like a logical way of doing this since I assume that for whatever
> > reason, there is a strict limit to only one generic SCSI target in the
> > Linux kernel, and obviously as per this thread the current one is
> > being replaced.
>
> Well, my preference would be to keep STGT. ?However, I indicated to both
> target infrastructures that if they could satisfy the above, I'd be OK
> with replacing STGT, so I'm not about to go back on that after causing
> quite a large amount of work.
And when did you indicate that ?
Sorry James, but the above looks to me like an interesting attempt to
rewrite history. What you repeated a few times in that thread from
January 2008 is that you were not convinced that a kernel-based
storage target could outperform a user-space target implementation. So
at least the impression was created that you were not going to accept
a kernel-based storage target for inclusion in the Linux kernel. In
another thread from December 2008 you repeated that view . A literal
quote from http://lkml.indiana.edu/hypermail/linux/kernel/0812.1/02168.html:
<quote>
The only identified failing of STGT (and it's theoretical, not
demonstrated, although I can agree the theory looks correct) is that the
user space packet processing may cause performance problems on high
speed networks. We know from practical tests that these networks have
to be above 1Gbit because the results were identical for STGT and SCST
on a 1G network, so it's infiniband or 10Gbit ethernet.
So, what it comes down to is that if we had a kernel side protocol
accelerator for STGT, the project would no longer suffer from this
theoretical failing. *Both* of you have such a thing embedded in your
respective submissions (all 74k LOC of them) so can't you just enhance
STGT with whichever one is better ... actually, if you'd both bury the
hatchet and work on the enhancement together taking the best of each
project, we'd have something that worked much better and a unified user
base and neither side would be able to claim sole credit ... just a
thought.
</quote>
While about two years ago you were not convinced that a kernel-based
storage target could outperform a user-space based storage target,
recently you announced that a kernel-based storage target is going to
be integrated. I have no problem that someone changes his opinion, but
you should not try to make people believe that you have always been in
favor of a kernel-based storage target.
Bart.
On Mon, 2010-08-23 at 19:44 +0200, Bart Van Assche wrote:
> On Mon, Aug 23, 2010 at 6:59 PM, James Bottomley
> <[email protected]> wrote:
> >
> > On Sun, 2010-08-22 at 18:10 -0400, Gennadiy Nerubayev wrote:
> > > [ ... ]
> > > Hi James,
> > >
> > > (disclaimer: I'm a hoi polloi SCST user)
> > >
> > > I'm not sure if I understand why there is a need for a replacement
> > > target to reuse existing code, and would definitely appreciate a brief
> > > explanation or a pointer to an earlier one.
> >
> > The best thread on the topic is this massive one:
> >
> > http://marc.info/?t=120109820100005
> >
> > I want replacement because evidence suggests that multiple things doing
> > the same thing don't get as much attention as a single one. We need to
> > support STGT because it's the one that has the in-kernel user base.
> > Just breaking them constitutes an ABI problem under the new kernel
> > rules.
> >
> > > But even that aside, I'm
> > > curious if the criteria for what a replacement target must have for
> > > (at least potential) inclusion into the kernel were ever clearly
> > > outlined in the past. If they were, then there probably would have
> > > been things like interested contenders, deadlines, feature
> > > comparisons, code reviews, and so on, right?
> >
> > Yes, in that thread.
> >
> > 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). If the two communities can't
> > work together (as seems to be the case) and I have to choose one, I'll
> > go by what helps me which, as I've said before, are:
> >
> > 1. That it would be a drop in replacement for STGT (our current
> > in-kernel target mode driver), since he only wanted a single
> > SCSI target infrastructure.
> >
> > 2. That it used a modern sysfs based control and configuration
> > plane.
> >
> > 3. That the code was reviewed as clean enough for inclusion.
> >
> >
> > > Now, I can't claim familiarity with the kernel development process, or
> > > any "political" workings in it. The aforementioned however would seem
> > > like a logical way of doing this since I assume that for whatever
> > > reason, there is a strict limit to only one generic SCSI target in the
> > > Linux kernel, and obviously as per this thread the current one is
> > > being replaced.
> >
> > Well, my preference would be to keep STGT. However, I indicated to both
> > target infrastructures that if they could satisfy the above, I'd be OK
> > with replacing STGT, so I'm not about to go back on that after causing
> > quite a large amount of work.
>
> And when did you indicate that ?
So 1. comes directly from what you quote below. The sysfs thing is
buried in another long thread that I can't be bothered to dig through
and 3. is a basic requirement from anything for inclusion.
> Sorry James, but the above looks to me like an interesting attempt to
> rewrite history. What you repeated a few times in that thread from
> January 2008 is that you were not convinced that a kernel-based
> storage target could outperform a user-space target implementation. So
> at least the impression was created that you were not going to accept
> a kernel-based storage target for inclusion in the Linux kernel. In
> another thread from December 2008 you repeated that view . A literal
> quote from http://lkml.indiana.edu/hypermail/linux/kernel/0812.1/02168.html:
To be honest, I can't see how you arrive at that interpretation from the
quote below. It specifically says "what it comes down to is that if we
had a kernel side protocol accelerator for STGT, the project would no
longer suffer from this theoretical failing. *Both* of you have such a
thing embedded in your respective submissions (all 74k LOC of them) so
can't you just enhance STGT with whichever one is better?" That's
reluctant acceptance, not the blanket refusal you ascribe to it.
James
> <quote>
> The only identified failing of STGT (and it's theoretical, not
> demonstrated, although I can agree the theory looks correct) is that the
> user space packet processing may cause performance problems on high
> speed networks. We know from practical tests that these networks have
> to be above 1Gbit because the results were identical for STGT and SCST
> on a 1G network, so it's infiniband or 10Gbit ethernet.
>
> So, what it comes down to is that if we had a kernel side protocol
> accelerator for STGT, the project would no longer suffer from this
> theoretical failing. *Both* of you have such a thing embedded in your
> respective submissions (all 74k LOC of them) so can't you just enhance
> STGT with whichever one is better ... actually, if you'd both bury the
> hatchet and work on the enhancement together taking the best of each
> project, we'd have something that worked much better and a unified user
> base and neither side would be able to claim sole credit ... just a
> thought.
> </quote>
>
> While about two years ago you were not convinced that a kernel-based
> storage target could outperform a user-space based storage target,
> recently you announced that a kernel-based storage target is going to
> be integrated. I have no problem that someone changes his opinion, but
> you should not try to make people believe that you have always been in
> favor of a kernel-based storage target.
>
> Bart.
Gennadiy Nerubayev, on 08/23/2010 02:10 AM wrote:
> I'm not sure if I understand why there is a need for a replacement
> target to reuse existing code, and would definitely appreciate a brief
> explanation or a pointer to an earlier one. But even that aside, I'm
> curious if the criteria for what a replacement target must have for
> (at least potential) inclusion into the kernel were ever clearly
> outlined in the past. If they were, then there probably would have
> been things like interested contenders, deadlines, feature
> comparisons, code reviews, and so on, right?
A fair public review of SCST code with a fair _public_ comparison
without any deals and conspiracy behind our back is, basically, all we
are asking. Let the best code win.
Vlad
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.
Vlad
On Mon, Aug 23, 2010 at 7:58 PM, James Bottomley
<[email protected]> wrote:
> On Mon, 2010-08-23 at 19:44 +0200, Bart Van Assche wrote:
>> On Mon, Aug 23, 2010 at 6:59 PM, James Bottomley
>> <[email protected]> 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). ?If the two communities can't
>> > work together (as seems to be the case) and I have to choose one, I'll
>> > go by what helps me which, as I've said before, are:
>> >
>> > ? ? 1. That it would be a drop in replacement for STGT (our current
>> > ? ? ? ?in-kernel target mode driver), since he only wanted a single
>> > ? ? ? ?SCSI target infrastructure.
>> >
>> > ? ? 2. That it used a modern sysfs based control and configuration
>> > ? ? ? ?plane.
>> >
>> > ? ? 3. That the code was reviewed as clean enough for inclusion.
Let us return to the three acceptance criteria. At this time none of
the existing kernel-based target frameworks support ibmvstgt and hence
none of them satisfy criterion [1]. Yet these criteria have been used
to decide that one kernel-based target framework will be accepted and
that the other will not be accepted. I'm afraid that I missed
something ?
Also, you write that you, as a kernel maintainer, might become in a
position that you have to choose a target framework. I would
appreciate it if you would take the time to reread the document
Documentation/ManagementStyle. This document was written by Linus
Torvalds and explains that a kernel maintainer should try to avoid
having to take such decisions. The whole first chapter of that
document is devoted to this subject.
I regret that you got involved personally in this discussion. It would
have been a lot easier for everyone if you would have been able to
keep a neutral position.
Bart.
On Mon, 2010-08-23 at 22:11 +0200, Bart Van Assche wrote:
> On Mon, Aug 23, 2010 at 7:58 PM, James Bottomley
> <[email protected]> wrote:
> > On Mon, 2010-08-23 at 19:44 +0200, Bart Van Assche wrote:
> >> On Mon, Aug 23, 2010 at 6:59 PM, James Bottomley
> >> <[email protected]> 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). If the two communities can't
> >> > work together (as seems to be the case) and I have to choose one, I'll
> >> > go by what helps me which, as I've said before, are:
> >> >
> >> > 1. That it would be a drop in replacement for STGT (our current
> >> > in-kernel target mode driver), since he only wanted a single
> >> > SCSI target infrastructure.
> >> >
> >> > 2. That it used a modern sysfs based control and configuration
> >> > plane.
> >> >
> >> > 3. That the code was reviewed as clean enough for inclusion.
>
> Let us return to the three acceptance criteria. At this time none of
> the existing kernel-based target frameworks support ibmvstgt and hence
> none of them satisfy criterion [1]. Yet these criteria have been used
> to decide that one kernel-based target framework will be accepted and
> that the other will not be accepted. I'm afraid that I missed
> something ?
>
> Also, you write that you, as a kernel maintainer, might become in a
> position that you have to choose a target framework. I would
> appreciate it if you would take the time to reread the document
> Documentation/ManagementStyle. This document was written by Linus
> Torvalds and explains that a kernel maintainer should try to avoid
> having to take such decisions. The whole first chapter of that
> document is devoted to this subject.
I have avoided this decision for several years in the vain hope that
some accommodation could be found. However, since I foresee a mergeable
patch in my inbox in the very near future, it's shortly becoming
unavoidable.
James
> I regret that you got involved personally in this discussion. It would
> have been a lot easier for everyone if you would have been able to
> keep a neutral position.
>
> Bart.
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.
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.
I'm sure STGT appreciates the frank assessments, but it doesn't seem to
merit too many "plays well with others" points.
James
On Mon, Aug 23, 2010 at 10:38 PM, James Bottomley
<[email protected]> 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.
>
> 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.
>
> I'm sure STGT appreciates the frank assessments, but it doesn't seem to
> merit too many "plays well with others" points.
Although it may not be clear from this thread, we respect the STGT
software and the all work the STGT authors have done to make it a
successful, stable and high performance storage target. The iSCSI-SCST
target driver even contains some of the code that was originally
written by an STGT author (Tomo) for a different project (IET).
A lot has already been discussed in this thread. It is already clear
that integrating LIO instead of SCST would hurt many SCST users. What
is not yet clear is what the consequences would be for LIO users if
SCST would be integrated instead of LIO ? A few months SCST has gained
support for persistent reservations (clustering). The SCSI engine of
SCST is powerful, and the core - target driver interface of SCST is a
rich interface. If there are any user-developed LIO target drivers,
it's probably relatively easy to port these to SCST.
Bart.
On Mon, Aug 23, 2010 at 3:38 PM, James Bottomley
<[email protected]> wrote:
> ? ? ?* 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.
>
> I'm sure STGT appreciates the frank assessments, but it doesn't seem to
> merit too many "plays well with others" points.
I get what you are saying, and I haven't use STGT, but if these things
are true (especially the last), well truth sometimes hurts,
and if they aren't true, why replace the target anyway?
There is also some precedence for dropping features, at least
temporarily and sometimes longer, to move to a new backend. In fact I
have a fax server that I still have to run on a specific 2.4 kernel
version because latter 2.4's and all 2.6's serial subsystem don't
quite work right with the old hardware. Sometimes you do have to drop
some old code to move forward, and hope someone that cares will fix
it, and sometimes there really is not enough users to bother with.
I haven't tried using LIO for nearly 3 years, at which point I was not
able to connect a VMware ESX initiator and transfer data reliably, and
Nick really didn't seem to care. SCST works, and Vlad worked quite
hard helping me both with config issues and code patches to making it
rock stable with great performance. If my memory serves, at the time
STGT was documented to have issues with ESX so i didn't even bother
testing it. I also rarely see any technical conversation on LIO
lists, I actually thought the project had gone slightly stale or
niche, until this thread.
Let me also toss this out there:
How many commercial iscsi products are based on LIO, and certified to
work with other commercial products?
I don't ask this because I think the kernel should listen to the whims
of commercial products, I ask because working with things that aren't
Linux is a clear sign of "plays well with others". Does LIO actually
play well with others, not just its lead developer?
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