Re: iSCSI initiator and media changer devices

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

  • Next message: Benoît Bousquet: "Re: Creating an IRP in serial filter driver, and using IoCallDriver" 
    Date: Sat, 7 Aug 2004 10:32:58 -0700

    We were not able to identify an issue with ILI handling. If there are any
    specifics, please send email to iscsibt. Thanks.

    "Jeff Goldner [MS]" <jeffgo@iworkatmicrosoft> wrote in message
    news:%23uSjT6qeEHA.592@TK2MSFTNGP11.phx.gbl...
    > 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
    >
    >

  • Next message: Benoît Bousquet: "Re: Creating an IRP in serial filter driver, and using IoCallDriver"