Re: iSCSI support for Linux

Re: iSCSI support for Linux

[Ashish A. Palekar]

Ben/Nitin:

I was going through some of the emails you guys had sent out on the LKML
about iscsi support. I think there is some confusion about the projects.

There are three different projects that I am aware of and are currently
active.

1. Cisco
2. Intel
3. UNH - Chris Loveland and myself were both from UNH and have since
graduated. However, there is still active development work.

As far as the UNH project goes:

We have been working on both the Initiator (host) and the Target
(Server) side. The Initiator side should work directly with the SCSI
Initiator mid-level. As I am given to understand, the code was revved up
to version 6.

On the Target side, the project is a little more elaborate. Since there
is no existing SCSI Target support, we have developed a SCSI Target
Mid-level. This has three front-ends written for it which support:

1. Adaptec's SCSI Encapsulation Protocol (defunct last November - since
iSCSI has become the dominant SAN over TCP/IP protocol)
2. QLogic ISP 2200 A Fibre Channel driver
3. iSCSI driver (and this works on the TCP/IP software stack which Linux
has) - so it is pretty much limited by whatever ethernet cards Linux
supports (including GigE). We did not have access to TCP accelerated
cards so the development on those has not been done.

Thus you have three target drivers written for the SCSI Target mid-level
which we has been written. For the iSCSI driver itself - there are four
target drivers one for rev 0, rev 03, rev 06 and rev 08.

The UNH drivers are available for download from:

http://www.iol.unh.edu/consortiums/fc/fc_linux.html
http://www.iol.unh.edu/consortiums/iscsi

They have been GPLed. Lots of people are currently trying out the code
and letting me and the other developers know about the bugs. Ideally, we
would like to fix those (however, the rev version of the draft keeps on
changing :-(). The Initiator code is fairly straightforward. For how to
use the target code, my thesis is available with the tar ball from one
of these sites.

Okay .. to your question about authentication Ben .. the consideration
we had to make was that a lot of the authentication stuff was to be done
in hardware by most companies developing iSCSI (I know very little about
authentication and security stuff so I may be completely wrong). From a
software development perspective it would have taken a decent amount of
time and the objective was to get code out so that it could be used for
protocol testing in an iSCSI plugfest.

Hope this clears some of the confusion. If you have any questions,
please let me know. Sorry for the long email.

Thanks
Ashish A. Palekar

Re: iSCSI support for Linux

[Jeff V. Merkey]

Emulex in their Fibre Channel Drivers, support a fiber Channel LAN driver
that uses
an iSCSI implementation on Linux.  You can get the code from their website.
It does
not appear to be a complete implementation, but it does work.  What is
missing is the
device side of the logic, which seems to be a lot of work, but perhaps
someone else
knows where the other side is.  I  have heard that the BSD CAM layer is
something
people are looking at providing in Linux.

Jeff

----- Original Message -----
From: "Ashish A. Palekar" <apalekar@trebia.com>
To: <greearb@candelatech.com>; <nitin.dhingra@dcmtech.co.in>;
<linux-kernel@vger.kernel.org>
Sent: Monday, October 29, 2001 12:29 PM
Subject: Re: iSCSI support for Linux


> Ben/Nitin:
>
> I was going through some of the emails you guys had sent out on the LKML
> about iscsi support. I think there is some confusion about the projects.
>
> There are three different projects that I am aware of and are currently
> active.
>
> 1. Cisco
> 2. Intel
> 3. UNH - Chris Loveland and myself were both from UNH and have since
> graduated. However, there is still active development work.
>
> As far as the UNH project goes:
>
> We have been working on both the Initiator (host) and the Target
> (Server) side. The Initiator side should work directly with the SCSI
> Initiator mid-level. As I am given to understand, the code was revved up
> to version 6.
>
> On the Target side, the project is a little more elaborate. Since there
> is no existing SCSI Target support, we have developed a SCSI Target
> Mid-level. This has three front-ends written for it which support:
>
> 1. Adaptec's SCSI Encapsulation Protocol (defunct last November - since
> iSCSI has become the dominant SAN over TCP/IP protocol)
> 2. QLogic ISP 2200 A Fibre Channel driver
> 3. iSCSI driver (and this works on the TCP/IP software stack which Linux
> has) - so it is pretty much limited by whatever ethernet cards Linux
> supports (including GigE). We did not have access to TCP accelerated
> cards so the development on those has not been done.
>
> Thus you have three target drivers written for the SCSI Target mid-level
> which we has been written. For the iSCSI driver itself - there are four
> target drivers one for rev 0, rev 03, rev 06 and rev 08.
>
> The UNH drivers are available for download from:
>
> http://www.iol.unh.edu/consortiums/fc/fc_linux.html
> http://www.iol.unh.edu/consortiums/iscsi
>
> They have been GPLed. Lots of people are currently trying out the code
> and letting me and the other developers know about the bugs. Ideally, we
> would like to fix those (however, the rev version of the draft keeps on
> changing :-(). The Initiator code is fairly straightforward. For how to
> use the target code, my thesis is available with the tar ball from one
> of these sites.
>
> Okay .. to your question about authentication Ben .. the consideration
> we had to make was that a lot of the authentication stuff was to be done
> in hardware by most companies developing iSCSI (I know very little about
> authentication and security stuff so I may be completely wrong). From a
> software development perspective it would have taken a decent amount of
> time and the objective was to get code out so that it could be used for
> protocol testing in an iSCSI plugfest.
>
> Hope this clears some of the confusion. If you have any questions,
> please let me know. Sorry for the long email.
>
> Thanks
> Ashish A. Palekar
>
> -
> 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/

RE: iSCSI support for Linux

[Nitin Dhingra]

Ashish,
	I have seen your and other codes as well, I see that everybody's
used lun field as supplied by 
middle layer right. No one is using 64-bit field acc. to SAM-2, but Linux
Scsi Subsystem doesn't support 64-bit
field it supports only 32-bit. Have you thought something about it and do
you have any solution to this?

Kindly cc me as I am no longer in the mailing list.

regards,
nitin

 -----Original Message-----
From: 	Ashish A. Palekar [mailto:apalekar@trebia.com] 
Sent:	Monday, October 29, 2001 11:29 AM
To:	greearb@candelatech.com; nitin.dhingra@dcmtech.co.in;
linux-kernel@vger.kernel.org
Subject:	Re: iSCSI support for Linux


Ben/Nitin:
I was going through some of the emails you guys had sent out on the LKML
about iscsi support. I think there is some confusion about the projects.
There are three different projects that I am aware of and are currently
active.
1.	Cisco
2.	Intel
3.	UNH - Chris Loveland and myself were both from UNH and have since
graduated. However, there is still active development work.

As far as the UNH project goes:
We have been working on both the Initiator (host) and the Target (Server)
side. The Initiator side should work directly with the SCSI Initiator
mid-level. As I am given to understand, the code was revved up to version 6.
On the Target side, the project is a little more elaborate. Since there is
no existing SCSI Target support, we have developed a SCSI Target Mid-level.
This has three front-ends written for it which support:
1.	Adaptec's SCSI Encapsulation Protocol (defunct last November - since
iSCSI has become the dominant SAN over TCP/IP protocol)
2.	QLogic ISP 2200 A Fibre Channel driver
3.	iSCSI driver (and this works on the TCP/IP software stack which
Linux has) - so it is pretty much limited by whatever ethernet cards Linux
supports (including GigE). We did not have access to TCP accelerated cards
so the development on those has not been done.

Thus you have three target drivers written for the SCSI Target mid-level
which we has been written. For the iSCSI driver itself - there are four
target drivers one for rev 0, rev 03, rev 06 and rev 08.
The UNH drivers are available for download from:
http://www.iol.unh.edu/consortiums/fc/fc_linux.html
http://www.iol.unh.edu/consortiums/iscsi
They have been GPLed. Lots of people are currently trying out the code and
letting me and the other developers know about the bugs. Ideally, we would
like to fix those (however, the rev version of the draft keeps on changing
:-(). The Initiator code is fairly straightforward. For how to use the
target code, my thesis is available with the tar ball from one of these
sites.
Okay .. to your question about authentication Ben .. the consideration we
had to make was that a lot of the authentication stuff was to be done in
hardware by most companies developing iSCSI (I know very little about
authentication and security stuff so I may be completely wrong). From a
software development perspective it would have taken a decent amount of time
and the objective was to get code out so that it could be used for protocol
testing in an iSCSI plugfest.
Hope this clears some of the confusion. If you have any questions, please
let me know. Sorry for the long email.
Thanks
Ashish A. Palekar

Re: iSCSI support for Linux

[Ashish A. Palekar]

Nitin:

The Target side does support 64 bit LUNs - as recommended by SAM-2. The
SCSI Target Mid-level definition for a LUN is a u64. (Note: The SCSI
Target Mid-Level is a completely different entity than the SCSI
Initiator Mid-Level). The question that is up in the air is how to use
those 64 bits for a good target representation.

The other thing is that 64 bit LUNs are __VERY_RARELY__ used in the SCSI
world that I am familiar with. So unless you are in a highly specialized
operation where all 64 bits are important to you, you can get by with 32
bit LUNs.

On the Initiator side, the LUN issue also needs to be addressed by the
SCSI Initiator Mid-Level. The person to speak to in this regard would be
Eric Youngdale (eric@andante.org). In fact the LUN issue along with the
scan code are some of things on the SCSI todo list - the scan thing
being especially important if you are doing fibre channel to enable
dynamic target discovery.

Hope this helps
Ashish

Nitin Dhingra wrote:
> 
> Ashish,
>         I have seen your and other codes as well, I see that everybody's
> used lun field as supplied by
> middle layer right. No one is using 64-bit field acc. to SAM-2, but Linux
> Scsi Subsystem doesn't support 64-bit
> field it supports only 32-bit. Have you thought something about it and do
> you have any solution to this?
> 
> Kindly cc me as I am no longer in the mailing list.
> 
> regards,
> nitin

Re: iSCSI support for Linux

[Matthew Jacob]

On Tue, 30 Oct 2001, Ashish A. Palekar wrote:

> Nitin:
>
> The Target side does support 64 bit LUNs - as recommended by SAM-2. The
> SCSI Target Mid-level definition for a LUN is a u64. (Note: The SCSI
> Target Mid-Level is a completely different entity than the SCSI
> Initiator Mid-Level). The question that is up in the air is how to use
> those 64 bits for a good target representation.

IIRC the top 2 bits of the first byte of the 8 byte lun define the layout-
this is what you have to look at on the initiator side when you do a REPORT
LUNS command.

>
> The other thing is that 64 bit LUNs are __VERY_RARELY__ used in the SCSI
> world that I am familiar with. So unless you are in a highly specialized
> operation where all 64 bits are important to you, you can get by with 32
> bit LUNs.
>

I'm not sure I agree. As we move into more and more virtualization types of
enviroments, the full 64 bit WWPN is often used as the 'lun'. So while it is
true that it's not important now, I suspect in a couple of years it might be.


> On the Initiator side, the LUN issue also needs to be addressed by the
> SCSI Initiator Mid-Level. The person to speak to in this regard would be
> Eric Youngdale (eric@andante.org). In fact the LUN issue along with the
> scan code are some of things on the SCSI todo list - the scan thing
> being especially important if you are doing fibre channel to enable
> dynamic target discovery.
>
> Hope this helps
> Ashish
>
> Nitin Dhingra wrote:
> >
> > Ashish,
> >         I have seen your and other codes as well, I see that everybody's
> > used lun field as supplied by
> > middle layer right. No one is using 64-bit field acc. to SAM-2, but Linux
> > Scsi Subsystem doesn't support 64-bit
> > field it supports only 32-bit. Have you thought something about it and do
> > you have any solution to this?
> >
> > Kindly cc me as I am no longer in the mailing list.
> >
> > regards,
> > nitin
> -
> 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/
>