Messages in this thread |  | | | Subject | LIO - the broken iSCSI target implementation | | From | Andreas Steinmetz <> | | Date | Thu, 17 Jan 2013 02:19:03 +0100 |
| |
This is not a technical point of view. This is a more or less political
and user point of view. And for any replies, I'm not subscribed (haven't
been now for years).
As a user, I was in need for an iSCSI target. Actually, I needed to
export a SAS tape device (Ultrium 5) - which is one of the devices still
sufficiently expensive to go the iSCSI target way) - well, not any disks
(cheap enough, NFS available) or CD/DVD writers (I'd call these penny
targets nowadays).
Thus, lio (http://www.linux-iscsi.org/) seemed to be the politically and
technically favoured solution. Except: it simply doesn't work, userspace
utilities are seemingly not maintained, the web site is - simply put -
sales talk and when one tries to write manually to configfs the results
are kernel panics.
A little bit more detail:
The mentioned website doesn't have any usable documentation on how to
use the provided utilities. It does, however, include lots of sales
pointers for a certain company. Looking at
http://www.risingtidesystems.com/git/ the latest changes are older than
3 months. And this userspace stuff is full of bugs. Whatever tool I
tried - either the tools complained or there were easily detectable bugs
that were never fixed.
Oh, well, maybe I do expect too much when a certain commercial
institution calls LIO "the standard open-source storage Target". Maybe
one should not expect typical hardware to be supported except, maybe,
when a commercial contract exists...
Though the only chance to get the LIO target working for me was to try
to write hopefully proper values to configfs manually. Without any
usable documentation, that is. The result was: kernel panics (@hch:
don't ask me how to repeat - hire some apes hacking at LIO configfs,
that's whats required, apes need no documentation, either).
The fun part of it was that I finally ended up using SCST - which was
refrained from kernel inclusion for technical reasons beyond my
knowledge. What makes me prefer SCST is quite simple:
It works, it is sufficiently documented and it is maintained. And, @hch:
Beautiful in kernel code first needs to work without producing kernel
panics (3.7.x) and it needs to be accompanied by working and
sufficiently documented user space utilities or, it needs to have a well
documented API (documentation needs to include a variety of examples,
not the old IBM way of simply documenting every flag without any
overview).
As long as LIO userspace is a not maintained and instead seemingly a
sales playground and as long as LIO kernel code causes panics by simple
writes to configfs LIO seems to me worse than any alpha quality code. It
is simply useless.
Maybe I'm the first to state this but for sure I'm not the first to
detect this.
Finally, I'm not willing to take part nor am I intending to start a
flame war. I'm just stating how things are with regards to LIO from a
user's point of view. It is up to other powers to decide, when and if
stuff gets fixed. It is, however, clear from a user's perspective that
LIO should be marked as *BROKEN* as long as it stays as unusable as it
is.
@hch - Remember: Implement, then *document* and *test*. Otherwise you
produce or review dead code - maybe even infradead code.
--
Andreas Steinmetz SPAMmers use robotrap@domdv.de
|  |
