|
»
« Return to Thread: ISCSI - does it work?
Re: Re: ISCSI - does it work?
by Mike Westerhof (mwester)
::
Rate this Message:
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)
> --- 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)
« Return to Thread: ISCSI - does it work?
| Free embeddable forum powered by Nabble | Forum Help |
