Andreas Krennmair
Guest
|
 Posted:
Thu Feb 10, 2005 2:09 am Post subject:
iSCSI userspace implementation? |
|
|
Hi,
I was having a quick look at iSCSI on Linux, and there seem to be a
number of solutions, both for using a Linux host as iSCSI initiator and as
iSCSI target. What I saw was that virtually every solution was
kernel-based, supported by some userspace daemon. I do understand that
this is the way to go for an initiator, but to me, it doesn't seem 100%
necessary to implement an iSCSI target on Linux using a kernel driver.
So my question to the iSCSI experts here: is it feasible to implement a
userspace-only daemon on Linux (or some other Unix-like operating
system) to act as an iSCSI target?
My (naive) idea was that the iSCSI node is stored to a single file (or
block device), access to it is done via mmap(2), and a daemon handles
the session, decodes the requests (that is the only really hard stuff,
IMHO), executes them on the file, and generates the responses. I don't
see where there would need to be involved any kernel-space programs. But
that's only my naive view, what do you say?
regards, ak |
|
Guest
|
| Posted:
Thu Feb 10, 2005 6:19 am Post subject:
Re: iSCSI userspace implementation? |
|
|
In article <20050209210944.GA2358@aon.at>,
Andreas Krennmair <ak@synflood.at> wrote:
| Quote: | Hi,
I was having a quick look at iSCSI on Linux, and there seem to be a
number of solutions, both for using a Linux host as iSCSI initiator and as
iSCSI target. What I saw was that virtually every solution was
kernel-based, supported by some userspace daemon. I do understand that
this is the way to go for an initiator, but to me, it doesn't seem 100%
necessary to implement an iSCSI target on Linux using a kernel driver.
So my question to the iSCSI experts here: is it feasible to implement a
userspace-only daemon on Linux (or some other Unix-like operating
system) to act as an iSCSI target?
My (naive) idea was that the iSCSI node is stored to a single file (or
block device), access to it is done via mmap(2), and a daemon handles
the session, decodes the requests (that is the only really hard stuff,
IMHO), executes them on the file, and generates the responses. I don't
see where there would need to be involved any kernel-space programs. But
that's only my naive view, what do you say?
regards, ak
|
A user-mode iSCSI target would certainly be doable. I'm actually
amazed that there are none that are freely distributable; there are
vague memories of Intel having released one ages ago. I'm sure that
most companies that work on iSCSI have testing or debugging versions
that are in user space (because it is much easier to work in user
space).
But for reasonably performance, you have to be in the kernel. Look at
it by counting the data transfers for a user-mode solution (here on
the example of a write): Data comes in over the IP network (typically
Ethernet) in ther kernel, has to be copied to user space. There the
iSCSI header is separated from the payload, and the payload goes back
into the kernel, to go to the disk or the filesystem that holds the
data. The number of user/kernel data transfers kills you. And the
even larger number of user/kernel transitions doesn't help either.
There are techniques to at least avoid the data copies (zero-copy
device drivers, memory shared between kernel and user mode), but using
them in an iSCSI or IP-based protocol ends up being just as difficult
as doing it in the kernel in the first place.
A user-mode iSCSI initiator is also theoretically doable, but it has
some of the same performance issues. Problem is that it is of just
about no use. What do you access with iSCSI? Mostly disk devices.
What do you do with disk devices? Mostly put file systems on them.
And file systems are in the kernel, and can't call back into user
space. (Yes, I know, they theoretically can call back into user
space, but performance and correctness in low-memory situations make
that into a demonstration experiment, rather than a production
solution).
--
The address in the header is invalid for obvious reasons. Please
reconstruct the address from the information below (look for _).
Ralph Becker-Szendy _firstname_@lr_dot_los-gatos_dot_ca.us |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in