* LIO - the broken iSCSI target implementation
@ 2013-01-17 1:19 Andreas Steinmetz
2013-01-17 20:56 ` Nicholas A. Bellinger
2013-01-18 1:53 ` Vladislav Bolkhovitin
0 siblings, 2 replies; 10+ messages in thread
From: Andreas Steinmetz @ 2013-01-17 1:19 UTC (permalink / raw)
To: linux-kernel; +Cc: hch, torvalds
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: LIO - the broken iSCSI target implementation
2013-01-17 1:19 LIO - the broken iSCSI target implementation Andreas Steinmetz
@ 2013-01-17 20:56 ` Nicholas A. Bellinger
2013-01-17 21:21 ` Nicholas A. Bellinger
2013-01-17 22:31 ` Andy Grover
2013-01-18 1:53 ` Vladislav Bolkhovitin
1 sibling, 2 replies; 10+ messages in thread
From: Nicholas A. Bellinger @ 2013-01-17 20:56 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: linux-kernel, hch, torvalds, target-devel
Hi Andreas,
On Thu, 2013-01-17 at 02:19 +0100, Andreas Steinmetz wrote:
> 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,
I'm not sure what you mean. There are targetcli+rtslib packages are
available for virtually every distribution
http://www.linux-iscsi.org/wiki/Targetcli#Linux_distributions
> the web site is - simply put -
> sales talk and when one tries to write manually to configfs the results
> are kernel panics.
Then your hitting a bug with pSCSI export with TYPE_TAPE. That's what
your trying to do right..?
>
> A little bit more detail:
>
> 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 full API reference for rtslib is available here:
http://www.risingtidesystems.com/doc/rtslib-gpl/html/
As for targetcli, you'll want to use the in-line documenation available
within the shell.
http://www.linux-iscsi.org/wiki/Targetcli#Display_helphttp://www.linux-iscsi.org/wiki/Targetcli#Display_help
> 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.
>
Of course LIO userspace is maintained. If you find a bug, please report
it to us so it can be addressed. Otherwise, I'm not sure what you
expect to achieve by simply hand-waving.
--nab
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: LIO - the broken iSCSI target implementation
2013-01-17 20:56 ` Nicholas A. Bellinger
@ 2013-01-17 21:21 ` Nicholas A. Bellinger
2013-01-17 22:31 ` Andy Grover
1 sibling, 0 replies; 10+ messages in thread
From: Nicholas A. Bellinger @ 2013-01-17 21:21 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: linux-kernel, hch, torvalds, target-devel
On Thu, 2013-01-17 at 12:56 -0800, Nicholas A. Bellinger wrote:
> Hi Andreas,
>
> On Thu, 2013-01-17 at 02:19 +0100, Andreas Steinmetz wrote:
> > 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,
>
> I'm not sure what you mean. There are targetcli+rtslib packages are
> available for virtually every distribution
>
> http://www.linux-iscsi.org/wiki/Targetcli#Linux_distributions
>
> > the web site is - simply put -
> > sales talk and when one tries to write manually to configfs the results
> > are kernel panics.
>
> Then your hitting a bug with pSCSI export with TYPE_TAPE. That's what
> your trying to do right..?
>
> >
> > A little bit more detail:
> >
> > 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 full API reference for rtslib is available here:
>
> http://www.risingtidesystems.com/doc/rtslib-gpl/html/
>
> As for targetcli, you'll want to use the in-line documenation available
> within the shell.
>
> http://www.linux-iscsi.org/wiki/Targetcli#Display_helphttp://www.linux-iscsi.org/wiki/Targetcli#Display_help
Also, as listed under:
http://www.linux-iscsi.org/wiki/Targetcli#Quick_start_guide
The community documentation for rtsadmin/targetcli is available in the
RTS-OS Admin manual here:
http://www.risingtidesystems.com/doc/RTS%20OS%20Admin%20Manual%20CE.pdf
The sections of interest for the end-user shell are:
5. RTSadmin Quick Start Guide
6. RTSadmin Concepts
7. RTSadmin Commands
8. RTSadmin Contexts
9. RTSadmin Examples
Again, if you've come across a bug with pSCSI + TYPE_TAPE export, please
let us know.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: LIO - the broken iSCSI target implementation
2013-01-17 20:56 ` Nicholas A. Bellinger
2013-01-17 21:21 ` Nicholas A. Bellinger
@ 2013-01-17 22:31 ` Andy Grover
2013-01-17 22:51 ` Linus Torvalds
` (2 more replies)
1 sibling, 3 replies; 10+ messages in thread
From: Andy Grover @ 2013-01-17 22:31 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Andreas Steinmetz, linux-kernel, hch, torvalds, target-devel,
Ritesh Raj Sarraf
On 01/17/2013 12:56 PM, Nicholas A. Bellinger wrote:
> On Thu, 2013-01-17 at 02:19 +0100, Andreas Steinmetz wrote:
>> 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,
>
> I'm not sure what you mean. There are targetcli+rtslib packages are
> available for virtually every distribution
>
> http://www.linux-iscsi.org/wiki/Targetcli#Linux_distributions
[CCing rrs@debian.org]
No... actually upstream targetcli/rtslib are not very well maintained.
Around 5 patches each in the last year.
Meanwhile, I have been actively maintaining branches at
github.com/agrover/targetcli-fb and github.com/agrover/rtslib-fb. We
have a man page and screencasts even. Feel free to file bugs against
them and I'll respond.
But I'm only packaging for Fedora/RHEL, so random people on Debian etc.
get a bad experience. I'd like to see upstream accept my AGPLv3-licensed
patches, or have Debian package the -fb versions, either instead or in
addition to the upstream versions.
(I'd kinda been waiting to bring it up until upstream had no commits in
a year, but since you mentioned it...)
Regards -- Andy
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LIO - the broken iSCSI target implementation
2013-01-17 22:31 ` Andy Grover
@ 2013-01-17 22:51 ` Linus Torvalds
2013-01-17 23:00 ` Nicholas A. Bellinger
2013-01-19 8:42 ` Ritesh Raj Sarraf
2 siblings, 0 replies; 10+ messages in thread
From: Linus Torvalds @ 2013-01-17 22:51 UTC (permalink / raw)
To: Andy Grover
Cc: Nicholas A. Bellinger, Andreas Steinmetz,
Linux Kernel Mailing List, Christoph Hellwig, target-devel,
Ritesh Raj Sarraf
On Thu, Jan 17, 2013 at 2:31 PM, Andy Grover <agrover@redhat.com> wrote:
>
> No... actually upstream targetcli/rtslib are not very well maintained.
> Around 5 patches each in the last year.
>
> Meanwhile, I have been actively maintaining branches at
> github.com/agrover/targetcli-fb and github.com/agrover/rtslib-fb. We
> have a man page and screencasts even. Feel free to file bugs against
> them and I'll respond.
If you look at the linux-iscsi.org link that Nicholas pointed at, it
actually does point to your targetcli-fb as the source package.
The fact that that Andreas then had a hard time finding documentation
and where to report problems, and things didn't work well for him is
obviously a problem, though.
And yes, he may have found the RTS repository because he followed the
Debian entry on linux-iscsi points not to your git tree, but to that
one, but hey, that's Debian. I sometimes suspect that they actively
search out the oldest possible source repository in their quest to be
"stable".
Linus
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: LIO - the broken iSCSI target implementation
2013-01-17 22:31 ` Andy Grover
2013-01-17 22:51 ` Linus Torvalds
@ 2013-01-17 23:00 ` Nicholas A. Bellinger
2013-01-19 8:42 ` Ritesh Raj Sarraf
2 siblings, 0 replies; 10+ messages in thread
From: Nicholas A. Bellinger @ 2013-01-17 23:00 UTC (permalink / raw)
To: Andy Grover
Cc: Andreas Steinmetz, linux-kernel, hch, torvalds, target-devel,
Ritesh Raj Sarraf
On Thu, 2013-01-17 at 14:31 -0800, Andy Grover wrote:
> On 01/17/2013 12:56 PM, Nicholas A. Bellinger wrote:
> > On Thu, 2013-01-17 at 02:19 +0100, Andreas Steinmetz wrote:
> >> 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,
> >
> > I'm not sure what you mean. There are targetcli+rtslib packages are
> > available for virtually every distribution
> >
> > http://www.linux-iscsi.org/wiki/Targetcli#Linux_distributions
>
> [CCing rrs@debian.org]
>
> No... actually upstream targetcli/rtslib are not very well maintained.
> Around 5 patches each in the last year.
>
> Meanwhile, I have been actively maintaining branches at
> github.com/agrover/targetcli-fb and github.com/agrover/rtslib-fb. We
> have a man page and screencasts even. Feel free to file bugs against
> them and I'll respond.
>
> But I'm only packaging for Fedora/RHEL, so random people on Debian etc.
> get a bad experience. I'd like to see upstream accept my AGPLv3-licensed
> patches, or have Debian package the -fb versions, either instead or in
> addition to the upstream versions.
>
So would I, but we've (RTS) been too busy having to work on other stuff
to pay the extensive legal bills from the fallout that your previous
public accusations have wrought.
Even though your over it, it doesn't mean other opportunists did not try
to take advantage of the situation once you got tired and moved onto
other target userspace related things.
> (I'd kinda been waiting to bring it up until upstream had no commits in
> a year, but since you mentioned it...)
In any event, I don't really have a problem with merging the two if your
finally over the fact the userspace code is AGPL licensed.
But please do this in a separate thread than piling on here. Of course,
your more than welcome to fix rtslib for pSCSI, which is broken on
recent v3.x kernels.
(Hint: it's because /sys/class/scsi_device/H:C:T:L/device/block/$BLOCK_DEV
no longer exists in upstream sysfs, which is what we use to match the passed
/dev/$SCSI_DEV to H:C:T:L, and nothing related to TCM ABI changes)
Thanks,
--nab
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: LIO - the broken iSCSI target implementation
2013-01-17 22:31 ` Andy Grover
2013-01-17 22:51 ` Linus Torvalds
2013-01-17 23:00 ` Nicholas A. Bellinger
@ 2013-01-19 8:42 ` Ritesh Raj Sarraf
2 siblings, 0 replies; 10+ messages in thread
From: Ritesh Raj Sarraf @ 2013-01-19 8:42 UTC (permalink / raw)
To: Andy Grover, Andreas Steinmetz
Cc: Nicholas A. Bellinger, linux-kernel, hch, torvalds, target-devel,
Kugesh Veeraraghavan
On Fri, Jan 18, 2013 at 4:01 AM, Andy Grover <agrover@redhat.com> wrote:
> On 01/17/2013 12:56 PM, Nicholas A. Bellinger wrote:
>> On Thu, 2013-01-17 at 02:19 +0100, Andreas Steinmetz wrote:
>>> 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,
>>
>> I'm not sure what you mean. There are targetcli+rtslib packages are
>> available for virtually every distribution
>>
>> http://www.linux-iscsi.org/wiki/Targetcli#Linux_distributions
>
> [CCing rrs@debian.org]
>
> No... actually upstream targetcli/rtslib are not very well maintained.
> Around 5 patches each in the last year.
>
I am not sure what errors you are facing but there are users already
using it. I just checked the iSCSI LIO Target, and it seems to work
fine in my limited tests.
If you run into issues, please file bug reports.
14:38:00 root@debian-x64:~# /etc/init.d/open-iscsi restart
[ ok ] Unmounting iscsi-backed filesystems: Unmounting all devices
marked _netdev.
[....] Disconnecting iSCSI targets:iscsiadm: No matching sessions found
. ok
[ ok ] Stopping iSCSI initiator service:.
[ ok ] Starting iSCSI initiator service: iscsid.
[....] Setting up iSCSI targets:
Logging in to [iface: default, target:
iqn.2003-01.org.linux-iscsi.debian-x64.x8664:sn.f32deae5534e, portal:
192.168.122.21,3260] (multiple)
Login to [iface: default, target:
iqn.2003-01.org.linux-iscsi.debian-x64.x8664:sn.f32deae5534e, portal:
192.168.122.21,3260] successful.
. ok
[ ok ] Mounting network filesystems:.
14:38:05 root@debian-x64:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
Codename: sid
14:38:22 root@debian-x64:~# uname -a
Linux debian-x64 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
We are currently under freeze for the Wheezy release. That is why you
don't see any updates. I could surely do latest and greatest updates
into experimental branch of the debian archive, but I have limited
volunteer time for Debian.
And anyways, there have not been much updates in the upstream
repositories, like Andy mentioned. Once the licensing issues are
sorted out, we will see which route we want to move ahead with.
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: LIO - the broken iSCSI target implementation
2013-01-17 1:19 LIO - the broken iSCSI target implementation Andreas Steinmetz
2013-01-17 20:56 ` Nicholas A. Bellinger
@ 2013-01-18 1:53 ` Vladislav Bolkhovitin
1 sibling, 0 replies; 10+ messages in thread
From: Vladislav Bolkhovitin @ 2013-01-18 1:53 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: linux-kernel, hch, torvalds
Andreas Steinmetz, on 01/16/2013 08:19 PM wrote:
> Thus, lio (http://www.linux-iscsi.org/) seemed to be the politically and
> technically favoured solution.
[...]
> 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.
No, it was purely political. There has never been any technical argument why LIO
is better. And can not be.
Thanks,
Vlad
^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <fa.9LtpVDEImZxRAaqPOyWMlGOK4Ow@ifi.uio.no>]
end of thread, other threads:[~2013-01-19 15:36 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-17 1:19 LIO - the broken iSCSI target implementation Andreas Steinmetz
2013-01-17 20:56 ` Nicholas A. Bellinger
2013-01-17 21:21 ` Nicholas A. Bellinger
2013-01-17 22:31 ` Andy Grover
2013-01-17 22:51 ` Linus Torvalds
2013-01-17 23:00 ` Nicholas A. Bellinger
2013-01-19 8:42 ` Ritesh Raj Sarraf
2013-01-18 1:53 ` Vladislav Bolkhovitin
[not found] <fa.9LtpVDEImZxRAaqPOyWMlGOK4Ow@ifi.uio.no>
[not found] ` <fa.xKOV9tOmjA6NPYEPagvZixrd/4w@ifi.uio.no>
2013-01-18 20:21 ` promo
2013-01-19 15:36 ` Fubo Chen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.