* Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
[not found] <4229e34e.7e535078.5bc3.0b5eSMTPIN_ADDED@mx.googlegroups.com>
@ 2005-03-06 1:02 ` Mike Christie
0 siblings, 0 replies; only message in thread
From: Mike Christie @ 2005-03-06 1:02 UTC (permalink / raw)
To: open-iscsi; +Cc: device-mapper development, linux-kernel, linux-scsi
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.
^ permalink raw reply [flat|nested] only message in thread