Messages in this thread | | | Date | Sat, 05 Mar 2005 17:02:15 -0800 | From | Mike Christie <> | Subject | Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux |
| |
Alex Aizman wrote: > This is to announce Open-iSCSI project: High-Performance iSCSI Initiator for > Linux. > > MOTIVATION > ========== > > Our initial motivations for the project were: (1) implement the right > user/kernel split, and (2) design iSCSI data path for performance. Recently > we added (3): get accepted into the mainline kernel. > > As far as user/kernel, the existing iSCSI initiators bloat the kernel with > ever-growing control plane code, including but not limited to: iSCSI > discovery, Login (Authentication and Operational), session and connection > management,
For iscsi-sfnet, I know it does login and auth and session and connection management/recovery in kernel becuase nobody has been able to write a usersapce daemon that can survive memory allocation failures and being paged out - are there other problems when dealing with usersapce like this. Open-iscsi seems to suffer from those problems too, but they seem like they can be fixed relatively quickly. Do you know how long it will take? Is it still two months with some of the items I descibed on the open-iscsi list in mind and after looking at what dm multipath has had to do to perform failback and path checking?
As you know I agree it should be done in usersapce so please spare me the usual advertisements and magic I normally get ;) I do not need to be sold on the concept. I am just trying to get a better picture of if people will merge the kernel part with a unreliable userspace component. If so then many sourceforge devs can help test as there is no point in target vendors on that list fixing the same bugs on multiple stacks like I have been doing (almost had Pyx fixed with IBM DS300 too).
If the problems of doing recovery/login/auth in usersapce are solved and well known should dm multipath move its failover to usersapce too? Doing explicit failover is essentialy the same problem and there is no point in sticking in a kernel interface for dm hw handlers when it can be done in usersapce. I mention this becuase of the MCS embargo, and the fact the I cannot imagine many storage admins running iSCSI without some sort of multipath or failover so I would like to get that ironed out too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |