If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 he 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 |
#2
|
|||
|
|||
In article ,
Andreas Krennmair wrote: 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 he 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 |
#3
|
|||
|
|||
A user-mode iSCSI initiator is also theoretically doable, but it has
User-mode block device driver? -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation http://www.storagecraft.com |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Can iSCSI work in 24/7 environment? | Rob Scott | Storage & Hardrives | 18 | January 7th 05 07:09 PM |
Real life case: build my own high-availability iSCSI SAN: howto? | news.xs4all.nl | Storage & Hardrives | 5 | October 14th 04 01:20 AM |
[ANN] STARWIND AND STARPORT iSCSI SOFTWARE SOLUTIONS WILL BE DISTRIBUTED AS FREE FOR NON COMMERCIAL USE. | Anton Kolomyeytsev | Storage & Hardrives | 0 | September 16th 04 08:51 AM |
iSCSI on NetAPP as Target and Windows 2003 Software initiator | Moshiko | Storage & Hardrives | 6 | February 17th 04 05:32 PM |
Server as an iSCSI target | idunno | Storage & Hardrives | 4 | October 28th 03 04:14 AM |