ISCSI - does it work?

[Charles Lindsey-2]

I see that slugosBE 4.8 is offering me modules
   kernel-module-iscsi-tcp
   kernel-module-libiscsi
   kernel-module-scsi-transport-iscsi

Does anybody here have experience of using them? I am looking to set up ISCSI targets (no need for initiators), and to do that what else will I need?

It would seems I would need the daemon iscsi-target (plus some /etc/init.d/iscsi-target), but these do not seem to be on offer (I have located possible sources for them on sourceforge). But then I  probably need something to conffigure CHAP, and a few man pages for the whole thing would come in handy.

But if it all works, then it would amount to a very handy way to access decives on the Slug (my main host, running Solaris 10, seems to have all the necessary handles to manage the initiator end, and it it works I could then access devices on the slug such as USB sticks and my CD/DVD gadget  as if thyey were sitting on my main hos)t.

[Neil Shephard]

--- In nslu2-linux@..., "Charles Lindsey" <clerew5@...> wrote:
>
> I see that slugosBE 4.8 is offering me modules
>    kernel-module-iscsi-tcp
>    kernel-module-libiscsi
>    kernel-module-scsi-transport-iscsi
>
> Does anybody here have experience of using them? I am looking to set up ISCSI targets (no need for initiators), and to do that what else will I need?

I've no experience with ISCSI I'm afraid, but these are all available under the more recent SlugOSBE-5.3....

# opkg list | grep 'iscsi'
kernel-module-iscsi-tcp - 2.6.27.8+svnr1085-r3 - iscsi-tcp kernel module; iSCSI/TCP data-path
kernel-module-libiscsi - 2.6.27.8+svnr1085-r3 - libiscsi kernel module; iSCSI library functions
kernel-module-scsi-transport-iscsi - 2.6.27.8+svnr1085-r3 - scsi-transport-iscsi kernel module; iSCSI Transport Interface

Neil

[Charles Lindsey-2]

--- In nslu2-linux@..., "Charles Lindsey" <clerew5@...> wrote:
>
> I see that slugosBE 4.8 is offering me modules
>    kernel-module-iscsi-tcp
>    kernel-module-libiscsi
>    kernel-module-scsi-transport-iscsi
>
> Does anybody here have experience of using them? I am looking to set up ISCSI targets (no need for initiators), and to do that what else will I need?

Well, having investigated further, it seems that those kernel modules are for ISCSI _initiators_, whereas what is needed is to use the SLug as an ISCSI _target_ (but even for an initiator, you would need the associated user-programs, such as iscsiadm - see www.open-iscsi.org).

For a _target_, it seems the fashionable implementation is IET (http://iscsitarget.sourceforge.net/), whose main component is the daemon ietd. The Good News is that it is all done in User Space (no kernel modules needed). The Bad News is that it is not available for the Slug anywhere (or, has anyone tried it). Anyway, I might have a go at it.

> But if it all works, then it would amount to a very handy way to access decives on the Slug (my main host, running Solaris 10, seems to have all the necessary handles to manage the initiator end, and it it works I could then access devices on the slug such as USB sticks and my CD/DVD gadget  as if thyey were sitting on my main hos)t.
>

[Mike Westerhof (mwester)]

Charles Lindsey wrote:

> I see that slugosBE 4.8 is offering me modules
>    kernel-module-iscsi-tcp
>    kernel-module-libiscsi
>    kernel-module-scsi-transport-iscsi
>
> Does anybody here have experience of using them? I am looking to set up ISCSI targets (no need for initiators), and to do that what else will I need?
>
> It would seems I would need the daemon iscsi-target (plus some /etc/init.d/iscsi-target), but these do not seem to be on offer (I have located possible sources for them on sourceforge). But then I  probably need something to conffigure CHAP, and a few man pages for the whole thing would come in handy.
>
> But if it all works, then it would amount to a very handy way to access decives on the Slug (my main host, running Solaris 10, seems to have all the necessary handles to manage the initiator end, and it it works I could then access devices on the slug such as USB sticks and my CD/DVD gadget  as if thyey were sitting on my main hos)t.

Other way around -- the modules above would be the "client" side of things.

The nature and intention of iscsi is so contrary to what the NSLU2 can
do that nobody has ever tried what you wish to do.  That's not to say
that it can't be done -- just to note that you'll be the pioneer blazing
a trail that few, if any, will follow ;-)

Mike (mwester)

[Charles Lindsey-2]

--- In nslu2-linux@..., "Mike Westerhof (mwester)" <mwester@...> wrote:

> Other way around -- the modules above would be the "client" side of things.

Yes I spotted that later.
>
> The nature and intention of iscsi is so contrary to what the NSLU2 can
> do that nobody has ever tried what you wish to do.  That's not to say
> that it can't be done -- just to note that you'll be the pioneer blazing
> a trail that few, if any, will follow ;-)

But I am surprised you say that. Surely the purpose of the NSLU2 is to access assorted devices across the network, and surely making it appear that the device is actually on your own machine is the ultimate solution to that problem?

(My immediate need was for accessing my CD/DVD device. I have managed to compile cdrtools for SlugosBE and it is sort of working. But dealing with stuff produced by Joerge Schilling is always a bit painful, so I was looking for an alternative method).

[Charles Lindsey-2]

--- In nslu2-linux@..., "Charles Lindsey" <clerew5@...> wrote:
>
> --- In nslu2-linux@..., "Charles Lindsey" <clerew5@> wrote:

> For a _target_, it seems the fashionable implementation is IET (http://iscsitarget.sourceforge.net/), whose main component is the daemon ietd. The Good News is that it is all done in User Space (no kernel modules needed). The Bad News is that it is not available for the Slug anywhere (or, has anyone tried it). Anyway, I might have a go at it.
>

But now the Bad News again. Having dowloaded the source for IET, it seems that it _does_ include a kernel moduile, and it also want to patch some other bits of kernel that it doen't like (though Slugos 5.3 might be clear of those). So it looks a bit more tricky than I had supposed.

[Mike Westerhof (mwester)]

Charles Lindsey wrote:

> --- In nslu2-linux@..., "Mike Westerhof (mwester)" <mwester@...> wrote:
>
>> Other way around -- the modules above would be the "client" side of things.
>
> Yes I spotted that later.
>> The nature and intention of iscsi is so contrary to what the NSLU2 can
>> do that nobody has ever tried what you wish to do.  That's not to say
>> that it can't be done -- just to note that you'll be the pioneer blazing
>> a trail that few, if any, will follow ;-)
>
> But I am surprised you say that. Surely the purpose of the NSLU2 is to access assorted devices across the network, and surely making it appear that the device is actually on your own machine is the ultimate solution to that problem?

It's an opinion; feel free to differ.  But for what it's worth, here's
my thinking on the issue:

If you look at various bits of technology for the NSLU2 based on
"concept", "protocol/architecture", and "implementation", you'll see
what I mean.

Consider, for example, Samba -- the concept is great; it's exactly what
the NSLU2 should be used to do.  The "protocol" (for lack of a better
term; think about the very high-level architecture of the on-the-wire
protocol) is not a great match, but that can be solved with mappings of
security sorts of things.  The implementation illustrates my point -- at
one time, the implementation of Samba was light-weight, and matched the
NSLU2 very well.  The latest version of Samba, however, have become far
too heavy-weight to be a good fit.  They work, but that's about all you
can say.

Consider NFS: the concept is brilliant -- as long as you don't need a
lot of security, and you don't worry too much about Windows hosts.  The
protocol is simplicity itself, and the implementation is lightweight and
reliable.  NFS is an outstanding match for the NSLU2, with the
constraint that it doesn't play well at all with Windows systems (rather
a significant conceptual limitation for most).

Now ISCSI: the concept also matches the NSLU2 very well.  It doesn't
work very well with Windows (yet), but the big conceptual "win" over NFS
is block-level access to a device over the network.  Cool.  I can't
speak to the "protocol/architecture" - I have a feeling that while the
security aspects may be heavy-weight, the actual data-moving part of the
protocol is probably well-suited to *nix systems (contrasting with the
Windows/SMB/Samba model which does not fit very well at all, resulting
in significant protocol overhead for some operations).  Unfortunately,
from what I've been able to determine, the "implementation" side of
things for ISCSI is not a great fit -- it's huge, relies on lots of
large libraries, and expects much infrastructure from the host.  Rather
like the latest Samba packages, as a matter of fact!

Digging into the ISCSI stuff more deeply, I was unable to get it to work
at all on my Fedora host - too much stuff, too many dependencies, too
much setup.  I'm sure it's a matter of determination -- if I spent
enough effort, or sought out someone who had done this before, I expect
I could make it work.  But it's just not a simple, easy thing to
configure and run.  In fact, it smelled of the latest Samba versions --
enormous packages, dependent upon internationalization, SSL, and
innumerable libraries, etc, etc.  But unlike Samba, where we have the
samba-essentials package that strips Samba back to a minimal
implementation that actually fits and runs well on the NSLU2, I could
find no such "essential" version of the ISCSI packages.

And neither do I expect that.  After all, if you read the docs
associated with ISCSI, you'll find that all the examples describe the
typical Linux system as the client, and the typical example server is
some massive commercial fileserver or some huge Linux mega-server with
terabytes of RAID disks and huge network bandwidth and gobs of RAM.

So, my conclusion is that ISCSI is a conceptual match for the NSLU2 and
similar devices, but that it's not a practical match (yet) due to the
lack of "tiny host" or "essential" server package.  If the on-the-wire
protocol turns out to be light-weight enough (i.e. does not require gobs
of RAM to cache data or maintain in-memory tables, etc.), it might turn
out to be a great way to access remote devices.

But another consideration is that ISCSI provides only block-level access
to the device on the server -- that precludes sharing.  It also
precludes filesystem-transparency.  These are things that Samba and NFS
provide, instead.  If you're ok with that, then basically what it comes
down to is that you are using the NSLU2 as a "USB extender", right?  You
plug a disk into your host, or you plug it into the NSLU2 and connect it
via ISCSI so that it looks like it was plugged directly into the host --
 that amounts to the same thing as a USB extender.  It turns out that
there is a Linux USB<->network<->USB protocol in the works -- that would
probably be a more practical solution than ISCSI, given the small size
of the NSLU2 (not to mention a great generic solution for lots of little
USB devices, if it works).

Finally, I'll mention that there is a package (don't recall the name
right now) that does "ATA-over-ethernet" -- basically this is like a
loopback filesystem that works over the network.  A file on the NSLU2
(or other) server is managed by a server process, and a kernel module on
the client system (NSLU2 or other) makes that file appear as a disk
device.  That package was available and tested on SlugOS 4.8-beta; I'm
not sure what the SlugOS 5.3-beta status is off the top of my head.
That package is very light-weight and from an implementation
point-of-view, it matches the NSLU2 very well.  I think that's a far
more practical solution than ISCSI for the NSLU2.

That's basically a stream-of-consciousness outlining why I think ISCSI
isn't a good fit -- my facts may be outdated, or outright wrong; if
anyone knows or feels differently, speak up!

Mike (mwester)

[Charles Lindsey-2]

--- In nslu2-linux@..., "Mike Westerhof (mwester)" <mwester@...> wrote:
>
> Charles Lindsey wrote:
> > --- In nslu2-linux@..., "Mike Westerhof (mwester)" <mwester@> wrote:

> >> The nature and intention of iscsi is so contrary to what the NSLU2 can
> >> do that nobody has ever tried what you wish to do.  That's not to say
> >> that it can't be done -- just to note that you'll be the pioneer blazing
> >> a trail that few, if any, will follow ;-)
> >
> > But I am surprised you say that. Surely the purpose of the NSLU2 is to access assorted devices across the network, and surely making it appear that the device is actually on your own machine is the ultimate solution to that problem?
>
> It's an opinion; feel free to differ.  But for what it's worth, here's
> my thinking on the issue:

> Now ISCSI: the concept also matches the NSLU2 very well.  It doesn't
> work very well with Windows (yet), but the big conceptual "win" over NFS
> is block-level access to a device over the network.  Cool.  I can't
> speak to the "protocol/architecture" - I have a feeling that while the
> security aspects may be heavy-weight, the actual data-moving part of the
> protocol is probably well-suited to *nix systems (contrasting with the
> Windows/SMB/Samba model which does not fit very well at all, resulting
> in significant protocol overhead for some operations).  Unfortunately,
> from what I've been able to determine, the "implementation" side of
> things for ISCSI is not a great fit -- it's huge, relies on lots of
> large libraries, and expects much infrastructure from the host.  Rather
> like the latest Samba packages, as a matter of fact!

So yes, we seem to agree on the level that its a neat and useful concept, but maybe the actual implementation will turn out to be a bad match.
>
> Digging into the ISCSI stuff more deeply, I was unable to get it to work
> at all on my Fedora host - too much stuff, too many dependencies, too
> much setup.

I have no experience of actually using ISCSI, but it seems that my present host has all the necessary handles ready to be used.

> So, my conclusion is that ISCSI is a conceptual match for the NSLU2 and
> similar devices, but that it's not a practical match (yet) due to the
> lack of "tiny host" or "essential" server package.  If the on-the-wire
> protocol turns out to be light-weight enough (i.e. does not require gobs
> of RAM to cache data or maintain in-memory tables, etc.), it might turn
> out to be a great way to access remote devices.

Yes, that RAM usage might be the killer. But I have no evidence either way as yet.
>
> But another consideration is that ISCSI provides only block-level access
> to the device on the server -- that precludes sharing.  It also
> precludes filesystem-transparency.  These are things that Samba and NFS
> provide, instead.  If you're ok with that, then basically what it comes
> down to is that you are using the NSLU2 as a "USB extender", right?

Right indeed.That is just what my Slug is intended to be (no other users on the network to get in the way).

> Finally, I'll mention that there is a package (don't recall the name
> right now) that does "ATA-over-ethernet" -- basically this is like a
> loopback filesystem that works over the network.

Yes, I was aware that solutions of that nature would be possible, but not aware of actual implementations. Any further information you could give would be welcome, especially if it has already been tried on 4.8.