linuxcon 2010...
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
Quoted 4 lines · Vladislav Bolkhovitin
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/
Quoted 9 lines
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.
Quoted 8 lines
- 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 tofileio_tgt.- STGT user space targets can use SCST backend via
scst_localmodule.Scst_localmodule 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".
Quoted 1 line
2. Don't you like something in the sysfs interface SCST has?
I don't think so ... from a cursory glance it looks functional.
Quoted 9 lines
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
Quoted 13 lines · James Bottomley, on 08/18/2010 12:30 AM wrote:
Quoted 13 lines
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 tofileio_tgt.
Quoted 8 lines
Quoted 4 lines
- STGT user space targets can use SCST backend via
scst_localmodule.Scst_localmodule 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?
Quoted 6 lines
Quoted 3 lines
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
Quoted 17 lines · Vladislav Bolkhovitin
Quoted 16 lines · James Bottomley, on 08/18/2010 12:30 AM wrote:
Quoted 16 lines
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 tofileio_tgt.- STGT user space targets can use SCST backend via
scst_localmodule.Scst_localmodule is ready and work very well.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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]?"
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
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
Quoted 22 lines · James Bottomley, on 08/19/2010 12:43 AM wrote:
Quoted 22 lines
Quoted 21 lines
Quoted 9 lines
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.Quoted 8 lines
- 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 tofileio_tgt.- STGT user space targets can use SCST backend via
scst_localmodule.Scst_localmodule 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".
Quoted 5 lines
Quoted 2 lines
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?
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 26 lines · Vladislav Bolkhovitin
Quoted 25 lines · James Bottomley, on 08/19/2010 12:43 AM wrote:
Quoted 24 lines
Quoted 13 lines
Quoted 13 lines
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 tofileio_tgt.Quoted 8 lines
Quoted 4 lines
- STGT user space targets can use SCST backend via
scst_localmodule.Scst_localmodule 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?
Quoted 8 lines
Quoted 2 lines
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
Quoted 33 lines · James Bottomley
Quoted 32 lines · Vladislav Bolkhovitin
Quoted 22 lines · James Bottomley, on 08/19/2010 12:43 AM wrote:
Quoted 22 lines
Quoted 21 lines
Quoted 9 lines
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.
Quoted 8 lines
- 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_localmodule.Scst_localmodule 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".
Quoted 5 lines
Quoted 2 lines
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..
Quoted 6 lines
Quoted 2 lines
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 42 lines · Gennadiy Nerubayev
Quoted 33 lines · James Bottomley
Quoted 32 lines · Vladislav Bolkhovitin
Quoted 22 lines · James Bottomley, on 08/19/2010 12:43 AM wrote:
Quoted 22 lines
Quoted 21 lines
Quoted 9 lines
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.Quoted 8 lines
- 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 tofileio_tgt.- STGT user space targets can use SCST backend via
scst_localmodule.Scst_localmodule 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".
Quoted 5 lines
Quoted 2 lines
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..
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
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
Quoted 54 lines · James Bottomley
Quoted 8 lines · Gennadiy Nerubayev
[ ... ]
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.
Quoted 6 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 56 lines · Bart Van Assche
Quoted 54 lines · James Bottomley
Quoted 8 lines · Gennadiy Nerubayev
[ ... ]
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.
Quoted 6 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 8 lines
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
Quoted 27 lines
<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.
Quoted 11 lines · James Bottomley
Quoted 10 lines · Bart Van Assche
Quoted 8 lines · James Bottomley
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:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 29 lines · Bart Van Assche
Quoted 11 lines · James Bottomley
Quoted 10 lines · Bart Van Assche
Quoted 8 lines · James Bottomley
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:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
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 ?
Quoted 7 lines
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
Quoted 5 lines
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.
Quoted 4 lines · 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
Quoted 9 lines · Vladislav Bolkhovitin
Quoted 4 lines · 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
Quoted 24 lines · James Bottomley
Quoted 9 lines · Vladislav Bolkhovitin
Quoted 4 lines · 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:
Quoted 7 lines
* 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 7 lines · James Bottomley
* 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · James Bottomley, on 08/24/2010 12:38 AM wrote:
Quoted 9 lines · Vladislav Bolkhovitin
Quoted 4 lines · 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.
Quoted 6 lines
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.
Quoted 10 lines
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.
Quoted 2 lines
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
Quoted 8 lines · 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