Re: [PATCH][RFC 21/23]: iSCSI target driver

[Nicholas A. Bellinger]

On Wed, 2008-12-10 at 22:01 +0300, Vladislav Bolkhovitin wrote:
> This patch contains iSCSI-SCST target driver. This driver is a heavily 
> modified forked with all respects IET 
> (http://iscsitarget.sourceforge.net). Modifications were aimed to make a 
> clearer, more reviewable and maintainable code as well as to fix many 
> problems and make many improvements. See 
> http://scst.sourceforge.net/target_iscsi.html for more details.
> 
> It has split user/kernel space architecture, where all management, 
> sessions creation, parameters negotiation, etc. made in user space and 
> data are transferred in the kernel space. Such architecture for iSCSI 
> processing was many times acknowledged as the right one. Particularly, 
> in-kernel iSCSI initiator (open-iscsi) has such architecture.
> 

Just as with the Open/iSCSI Initiator, IMHO I believe the split
architecture design is difficult both to improve, debug and maintain,
and provides *ZERO* additional benefit in the context of traditional
iSCSI target mode for doing login and connection/session setup in
userspace.

Also, I appericate that you spent alot of time porting over IET code to
your engine, but during our previous discussion you did not seem
terribly interested in validation against core-iscsi-dv
(http://linux-iscsi.org/index.php/Core-iscsi-dv) to test RFC-3720
interopt and stability.  Because the Core-iSCSI Initiator supports every
possible parameter combination up to ErrorRecoveryLevel=0 defined in
RFC-3720, the Core-iSCSI-Dv tests can run badblocks (or any too) to
check data integrity for *EVERY* possible traditional iSCSI key
combination and functionality for your iSCSI-SCST work, and any type of
serious iSCSI-SCST production deployments.

Until you can at least do that to prove both the stability and
completeness of your iSCSI Target stack up to RFC-3720
ErrorRecoveryLevel=0, I don't think this code makes sense for any type
of mainline acceptance.  Also, I would appericate if you could stop the
handwaving about MC/S and ErrorRecoveryLevel=2 as well.  MC/S (multiple
connection paths for iSCSI/TCP, not necessary with multiple assoication
LIO-Target SCTP) and ERL=2 (OS independent fabric recovery) is available
in both RFC-3720 (Traditional iSCSI) and RFC-5045 (iSER for iWARP and
IB).

Trying to argue against implementing the complete iSCSI RFC
functionality (like some folks did during the early Open/iSCSI days)
that customers and users *WANT* now is going to fall of deaf ears.
Please understand that they are going to be many, many different iSCSi
Initiators connecting to the upstream iSCSI Target Core infrastructure,
and trying to rush in an incomplete iSCSI Target $FABRIC_MOD
implementation benefits anyone.

Regards,

--nab

> Signed-off-by: Vladislav Bolkhovitin <vst@xxxxxxxx>
> ---
>   drivers/scst/iscsi-scst/Kconfig     |   25
>   drivers/scst/iscsi-scst/Makefile    |    6
>   drivers/scst/iscsi-scst/config.c    |  597 +++++++
>   drivers/scst/iscsi-scst/conn.c      |  488 +++++
>   drivers/scst/iscsi-scst/digest.c    |  221 ++
>   drivers/scst/iscsi-scst/digest.h    |   31
>   drivers/scst/iscsi-scst/event.c     |  116 +
>   drivers/scst/iscsi-scst/iscsi.c     | 3066 ++++++++++++++++++++++++++++++++++++
>   drivers/scst/iscsi-scst/iscsi.h     |  577 ++++++
>   drivers/scst/iscsi-scst/iscsi_dbg.h |   73
>   drivers/scst/iscsi-scst/iscsi_hdr.h |  517 ++++++
>   drivers/scst/iscsi-scst/nthread.c   | 1522 +++++++++++++++++
>   drivers/scst/iscsi-scst/param.c     |  263 +++
>   drivers/scst/iscsi-scst/session.c   |  210 ++
>   drivers/scst/iscsi-scst/target.c    |  306 +++
>   include/scst/iscsi_scst.h           |  156 +
>   include/scst/iscsi_scst_ver.h       |   16
>   17 files changed, 8190 insertions(+)
> 
> The patch is too big to be submitted inline. You can find it in 
> http://scst.sourceforge.net/patches/iscsi-scst.diff
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/