[ofw] RE: [Scst-devel] SRP and DMIO - Windows Dynamic Disk

[Sufficool, Stanley]

> -----Original Message-----
> From: Vladislav Bolkhovitin [mailto:vst at vlnb.net] 
> Sent: Monday, March 16, 2009 10:16 AM
> To: Sufficool, Stanley
> Cc: ofw at lists.openfabrics.org; scst-devel; Vu Pham
> Subject: Re: [Scst-devel] SRP and DMIO - Windows Dynamic Disk
> 
> 
> Sufficool, Stanley, on 03/14/2009 12:19 AM wrote:
> > Using Windows SRP (WinOF_2-2030_wnet_64)  / Linux SCST+SRPT 
> (svn 695)
> > with dynamic disks leads to some strange behavior when the 
> initiator is 
> > rebooted. All basic disks come back online just fine. The 
> dynamic disks 
> > show up multiple times under the same names in disk manager, all as 
> > offline or unreadable. The basic disks show as unreadable in disk 
> > management even though they are connected and working fine. 
> I expect to 
> > see the dynamic disks as offline since the IB and SRP 
> devices come up 
> > after DMIO. I can script to bring these disks online after boot.
> >  
> > If I perform a disk rescan in disk manager to try and recover the
> > dynamic disks, then all my basic disks that were previously 
> > working disappear as well.
> >  
> > Event logs from the Windows LDM service are:
> > 
> > *LDM Event: *INTERNAL Error - No valid disk belonging to the disk 
> > group
> > was found (C1000096).
> > 
> > *LDM Event:* Unexpected failure. Error code: 2 at 0200001D 
> > <mailto:2 at 0200001D>
> > 
> > Stopping then restarting the WinOF SRP Miniport Device restores my 
> > basic
> > disk, but only one dynamic disk comes back online (with failed 
> > redundancy). The following doesn't look right either. Does 
> this have to 
> > do with the MPIO from the MS iSCSI initiator package?
> > 
> > *PartMgr Event:* Disk 3 will not be used because it is a redundant 
> > path
> > for disk 2.
> > 
> > Restarting the target with the initiator left online gives the same 
> > result.
> > 
> > *PartMgr Event: *Disk 3 will not be used because it is a redundant 
> > path
> > for disk 2.
> > 
> > I have attached the SCST messages from the target using the 
> debug and
> > extracheck build of SCST.
> > I have the target setup for the dynamic disks as 500MB vdisk file 
> > targets with 512 block sizes.
> >  
> > BTW: This works just fine using the SCST + iSCSI target 
> with MS iSCSI
> > initiator. Maybe because the iSCSI initiator timing issues 
> put it way 
> > farther back in the load process behind the network stack 
> and DMIO/LDM 
> > service.
> 
> I don't see anything wrong in the SCST log. According to it initiator 
> only 2 times open/closed session (restarted?). If you enable SCSI 
> logging, we can see all going SCSI commands and can say more.

echo "all" > trace_level

Please see attached message. Hope this helps locate the issue.

> 
> Since iSCSI target works fine, then the issue must be either with SRP 
> target, or SRP initiator, or Windows setup. For instance, 
> Windows after 
> restart doesn't recognize the target's devices as the same those were 
> before. Hopefully, Vu can comment on it better.
> 
> Do you use MPIO? Windows for MPIO needs a transport specific DSM. MS 
> iSCSI initiator package has it, but how about Windows SRP initiator?

I am not explicitly using DMIO, however there are 2 posrt and 2 paths to
the target. If SRP detects this without configuration then maybe.

> 
> Vlad
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: messages
Type: application/octet-stream
Size: 4031654 bytes
Desc: messages
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20090316/bfd37b64/attachment.obj>