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:[email protected]]
Sent: Monday, October 29, 2001 11:29 AM
To: [email protected]; [email protected];
[email protected]
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
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 ([email protected]). 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
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 ([email protected]). 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>