Some background history of the Features comparison page.

LIO was the first who has had similar comparison . It was and still is very much wrong about SCST. I asked that page author, Nicholas Bellinger, to correct the wrong items (see my e-mail), but Nicholas Bellinger refused to do it without any explanations. Moreover, he blocked my access to the LIO mailing list, preventing me from telling that to the interested people myself. After all our previous discussions and with his skills and experience it's nearly impossible to believe that Nicholas Bellinger didn't know that SCST is a lot more generic than LIO and has zero-copy in all the same places, where LIO has. Thus, that comparison page is looking like rather a deliberate cheating attempt. Seems SCST is so much superior over LIO, so Nicholas Bellinger gave up technical discussions and started attacking people's perception about SCST, trying to inspire them the opposite.

Update

After our comparison page was published, Nicholas Bellinger corrected in his comparison page the most crying items about SCST. Namely: he acknowledged that SCST is a generic engine as well as marked "zero-copy" item for SCST as "Needs kernel patch" and removed "User Interface" item. But "zero-copy" mark for SCST is still wrong, because SCST needs kernel patch to provide send zero-copy in the iSCSI target driver (and only in it) only if it is working with user space backend. LIO doesn't support user space backend, so, if it has "X" in this line, SCST must also have unconditional "X" there.

Moreover, new wrong items where introduced:

  • SCST was marked as "-" in "Additional Header Segment" and "Bidirectional Commands" items. SCST and iSCSI-SCST support bidirectional commands as well as iSCSI-SCST supports other values in the Additional Header Segment (namely, extended CDB).
  • STGT marked as having Fibre Channel target drivers for Emulex, QLogic and LSI adapters. Where are they?
  • STGT marked as having Fibre Channel QLogic target driver in-tree. Which tree is meant?
  • STGT marked as supporting SAS and parallel SCSI targets. But it fundamentally can't do that. Those transports don't provide expecting transfers values (size and direction), so those values must be extracted directly from CDBs. STGT doesn't have the necessary infrastructure for that, see, for instance, "https://lists.berlios.de/pipermail/stgt-devel/2007-March/000436.html. Nothing has changed since time, when that e-mail was sent.

Interesting coincidence that the above wrong STGT items were added at nearly the same time as LIO started working with STGT's in-kernel target drivers...