Re: iSCSI initiator and media changer devices

From: Jeff Goldner [MS] (jeffgo_at_iworkatmicrosoft)
Date: 08/05/04 

Date: Wed, 4 Aug 2004 22:39:36 -0700

First, I want people to know that Microsoft does take these criticisms
seriously. The big problem is that there are so many places that people make
comments that it's very difficult to track. That's why we post aliases in
conspicuous places. For iSCSI bugs, the alias for bug reporting is posted on
the iSCSI download page - it's iSCSIbt@microsoft.com. Sorry that we can't
promise to personally respond.

Now, as has been pointed out by Maxim and others, the appropriate mechanisms
for device detection are provided through SetupDi. Trolling the registry is
problematic, not to mention static. If vendors believe that reading the
devicemap once when they initialize a service is sufficient, they are going
to miss out on the wonderful and dynamic world of Storage Area Networks (and
all kinds of hotplug devices for that matter, including USB and 1394, in
addition to iSCSI and FC). What may have worked in NT4 (we shipped that in
1996) is not "by design" in 2004. Why, some people actually think a target
ID is meaningful as if you had a thumbwheel switch on the back of an iSCSI
target!

I have filed Windows bugs for the two concrete issues Anton brings up here
(improper SILI bit handling and inability to specify >256k transfer sizes);
both will be addressed in a future release of iSCSI.

For the less concrete perf claims, we constantly look at performance as do
our performance teams. But again this is hard to quantify sometimes. We will
continue to scrutinize this. Note that we try not to base claims on Iometer
but instead use workload simulations such as Jetstress and Sqlio since in
the real world Iometer doesn't match what our customers run. It's far more
interesting to them if we can solve their business problems and I can tell
you that about 1000 customers are in production today because we

Thanks everyone for your interest in iSCSI and your patience.

Jeff

"Anton Kolomyeytsev" <anton@rocketdivision.com> wrote in message
news:d4d1b20e.0407291354.56b82ec0@posting.google.com...
>I would say "not always". Some software relies on the fact DEVICEMAP
> key should exist and set to correct values. Here is what one of our
> customers wrote about why their company switched to our iSCSI
> initiator called StarPort and skipped using MS one:
>
> "Well, I thought that perhaps I might have fewer problems with the MS
> product. So far... wrong. These may be arcane problems but so far I
> have TWO concerns with msinitator. I have tried to notify MS of this,
> but who knows if it will be read? Problem #1: The latest 1.04b version
> contains a driver that is NOT mshql certified for Win2K. Go figger!
> Next problem: the MS initiator does not seem to create the following
> registry value entry: HKEY_Local_Machine\Hardware\Devicemap\SCSI\SCSI
> Port #\Driver (REG_SZ: IScsiPrt) which one might think it SHOULD
> create. (where #= SCSI # for the iscsi initiator hba) This has the
> untoward consequence that other programs, such as Veritas Backup Exec
> 9.x Disaster Recovery, fail to enumerate the SCSI values it needs
> (since the key may not exist.) and cannot create a bootable CD. Who
> KNOWS whether it is OK to add this value to fix the programs? So,
> Starport at least doesn't have this problem. ms iscsi requires
> W2K/XP/2003, I don't know whether Starport will work on w9x or
> otherwise." (c) ...
>
> I think this is EXACTLY what original requestor hit. DEVICEMAP issue!
>
> This is not the only problem with MS iSCSI initiator. It still has
> constant problems with supporting true hardware mapped as iSCSI. It
> does not support partial transfers properly (CHECK CONDITION situation
> with raised ILI flag -- quite common for f.e. tape devices returning
> partial data for large request -- MS treat this as ERROR situation
> failing SPTI request while this is NOT an error). It prevents at least
> some of the tape backup applications from working properly. Also MS
> does not allows to set manually largerst request size and always use
> 256K as buffer size (reporting it with IOCTL_STORAGE_QUERY_PROPERTY
> targeted to adapter PDO). It's OK for a virtual hardware on the other
> side supporting all possible transfer size. But let's imagine we have
> a situation when iSCSI target is mapping physical hardware as iSCSI.
> So we have single request not larger then 128K (SATA or ATA devices,
> ever seen more?). And as altering SCSI traffic (breaking the command
> into serie of ones or replacing the CDB with another one) is a
> definite "no-no" this means no single true hardware device bridged
> thru the dumb iSCSI target can be accessed by using MS iSCSI
> initiator. If SPTI software would not be wise enough to use smallest
> possible transfer size (64K usually). So Nero can burn to remote
> burner just b/s it used buffer size not larger then 64K and f.e.
> CdCheck fails to verify the disc b/s it uses largers reported buffer
> size and gets 256K from MS while other side cannot process more then
> 128K... I would consider this (blindness not to allow to control the
> value) as a **BUG**. This is the issue for SPTI software as file
> system driver requests are broken into 64K chunks
> (MM_MAXIMUM_DISK_IO_SIZE) by class driver. Seems like MS iSCSI
> initiator was tested with virtual hard disks as target devices only.
>
> While DEVICEMAP key and signing issue was not verified by me with
> latest 1.05 version of MS iSCSI initiator, 256K buffer and broken ILI
> support is still there. Tother with performance issues (I just cannot
> understand why MS shows sometimes quite a bad results, approx. 2.5
> times less sustained transfer rate compared with StarPort running on
> Windows box and UNH initiator running on Linux, measured with I/O
> meter) while iSCSI handshake parameters are the same. Also there is
> WinTarget issue (have you ever tried to log into freeware WinTarget,
> Windows UNH port?) and ERL 1 and ERL 2 question. Is this only me
> stupid who cannot coonnect to target with ERL 1 or ERL 2 enabled or MS
> just does not support anything except ERL **ZERO**? We need f.e. NAT
> and different networks to provide failover (network bridge is dead, we
> want to switch to other network interface and other bridge). What
> should we do now? Wait for somebody else to release iSCSI initiator
> with ERL 1 and ERL 2 for money?
>
> With MS iSCSI initiator more or less BROKEN and MS iSCSI target
> totally MISSING I would think about "MS iSCSI program" as a winner in
> "Disappointment of the year 2004" program. Cast my vote please!
>
> Regards,
> Anton Kolomyeytsev
>
> CEO, Rocket Division Software
>
> P.S. Sorry if I've hurt somebody's feelings. Some time ago I've
> answered to somebody from MS to "Q: Why are you using own iSCSI
> initiator and not using our one? A: Just b/s your one does not work!"
> It passed more then 2 monthes and nothing seems to change so far. We
> would **LOVE** to help and make your software better and people's life
> easier! The problem is nobady seems to be interested in our help... :(
>
> A. K.
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:<#TmvoaXdEHA.2664@TK2MSFTNGP09.phx.gbl>...
>> Use SetupDi APIs instead of DeviceMap. DeviceMap is obsolete, and is
>> possibly ill supported in iSCSI port.
>>
>> --
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> maxim@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> "chejlava" <chejlava@discussions.microsoft.com> wrote in message
>> news:BA77691A-93D9-45A1-BCB1-A8E74CF806B2@microsoft.com...
>> > Have been playing with various revs of the iSCSI inititator, and while
>> > I can
>> easily see and use tape drives connected to an ADIC iSCSI bridge, I
>> cannot use
>> the media changer (tape library) that is also connected.
>> >
>> > The changer does not show up in the registry's Devicemap (the tape
>> > drives do
>> show up), but oddly, it _does_ show up in the Device Manager, with the
>> expected
>> Bus/target/LUN numbers.
>> >
>> > We use the SCSI passthrough IOCTLs to control changers, but if they
>> > don't
>> show up in the Devicemap, we can't find them...
>> >
>> > In the initiator's Active Sessions/Details tab, it shows the two tape
>> > drives
>> of type "Tape", but the changer and the iSCSI bridge's "SCSI Porcessor
>> Device"
>> are shown as Name = Unavailable, Type = Unknown.
>> >
>> > I _think_ I saw somewhat better results in older versions of the
>> > initiator (I
>> could at least "see" the changer, but I still couldn't send it
>> commands).
>> >
>> > thanks
>> >
>> > --
>> > chejlava/Legato