Storport & Target Resets - Storage

This is a discussion on Storport & Target Resets - Storage ; Hi, I have a MSCS cluster running FC attached storage. We are using storport because I was under the impression that it did Lun Resets to clear reservations in the event of a path failover ( we are also using ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Storport & Target Resets

  1. Storport & Target Resets

    Hi, I have a MSCS cluster running FC attached storage. We are using
    storport because I was under the impression that it did Lun Resets to
    clear reservations in the event of a path failover ( we are also using
    MPIO with a Failover Only policy). However when I take a fibre channel
    trace, I see that in addition to the LUN resets (when the failing path
    is repaired ) there is also a Target Reset. This is very disruptive,
    and I cannot tell where this request is coming from. Has anyone seen
    this behavior? Also do you know of a way to suppress the TRs and to
    rely only on LR for clearing of reservation conflicts.

    Any help is most appreciated.

    Luis


  2. Re: Storport & Target Resets

    On Jun 5, 10:43 am, lec wrote:
    > Hi, I have a MSCS cluster running FC attached storage. We are using
    > storport because I was under the impression that it did Lun Resets to
    > clear reservations in the event of a path failover ( we are also using
    > MPIO with a Failover Only policy). However when I take a fibre channel
    > trace, I see that in addition to the LUN resets (when the failing path
    > is repaired ) there is also a Target Reset. This is very disruptive,
    > and I cannot tell where this request is coming from. Has anyone seen
    > this behavior? Also do you know of a way to suppress the TRs and to
    > rely only on LR for clearing of reservation conflicts.
    >
    > Any help is most appreciated.
    >
    > Luis


    Sorry, I forgot to fill in some details. I am running win2k3 SP2 and
    currently using emulex LP10000 cards.
    Luis


  3. Re: Storport & Target Resets

    Since you are using FCP MPIO, I suggest you contact your MPIO vendor
    (storage vendor). The DSM provided by your vendor could indeed be
    sending a TARGET/BUS RESET instead of a LUN reset. There is an IOCTL
    for using a hierarchical reset (i.e. LUN then TARGET then BUS) but it
    must be used by the DSM.

    I have seen Qlogic HBA's send spurious bus and target resets, but not
    Emulex. Also, make sure you are using the latest driver supported by
    your storage vendor.

    ~kenny

    lec wrote:
    > On Jun 5, 10:43 am, lec wrote:
    >> Hi, I have a MSCS cluster running FC attached storage. We are using
    >> storport because I was under the impression that it did Lun Resets to
    >> clear reservations in the event of a path failover ( we are also using
    >> MPIO with a Failover Only policy). However when I take a fibre channel
    >> trace, I see that in addition to the LUN resets (when the failing path
    >> is repaired ) there is also a Target Reset. This is very disruptive,
    >> and I cannot tell where this request is coming from. Has anyone seen
    >> this behavior? Also do you know of a way to suppress the TRs and to
    >> rely only on LR for clearing of reservation conflicts.
    >>
    >> Any help is most appreciated.
    >>
    >> Luis

    >
    > Sorry, I forgot to fill in some details. I am running win2k3 SP2 and
    > currently using emulex LP10000 cards.
    > Luis
    >


  4. Re: Storport & Target Resets

    On Jun 5, 12:23 pm, Kenny Speer wrote:
    > Since you are using FCP MPIO, I suggest you contact your MPIO vendor
    > (storage vendor). The DSM provided by your vendor could indeed be
    > sending a TARGET/BUS RESET instead of a LUN reset. There is an IOCTL
    > for using a hierarchical reset (i.e. LUN then TARGET then BUS) but it
    > must be used by the DSM.
    >
    > I have seen Qlogic HBA's send spurious bus and target resets, but not
    > Emulex. Also, make sure you are using the latest driver supported by
    > your storage vendor.
    >
    > ~kenny
    >
    > lec wrote:
    > > On Jun 5, 10:43 am, lec wrote:
    > >> Hi, I have a MSCS cluster running FC attached storage. We are using
    > >> storport because I was under the impression that it did Lun Resets to
    > >> clear reservations in the event of a path failover ( we are also using
    > >> MPIO with a Failover Only policy). However when I take a fibre channel
    > >> trace, I see that in addition to the LUN resets (when the failing path
    > >> is repaired ) there is also a Target Reset. This is very disruptive,
    > >> and I cannot tell where this request is coming from. Has anyone seen
    > >> this behavior? Also do you know of a way to suppress the TRs and to
    > >> rely only on LR for clearing of reservation conflicts.

    >
    > >> Any help is most appreciated.

    >
    > >> Luis

    >
    > > Sorry, I forgot to fill in some details. I am running win2k3 SP2 and
    > > currently using emulex LP10000 cards.
    > > Luis


    Thanks Kenny. The DSM code does have seem to issue either the
    IOCTL_STORAGE_BUS_RESET for the win2k case, and the
    IOCTL_STORAGE_BREAK_RESERVATION for the win2k3 case buy it was my
    understanding that these were interpreted by the bus driver (MPIO.sys)
    and that they ( at least I hope the IOCTL_STORAGE_BREAK_RESERVATION )
    would result on a LUN reset if storport is running.

    Luis


  5. Re: Storport & Target Resets

    lec wrote:
    > On Jun 5, 12:23 pm, Kenny Speer wrote:
    >> Since you are using FCP MPIO, I suggest you contact your MPIO vendor
    >> (storage vendor). The DSM provided by your vendor could indeed be
    >> sending a TARGET/BUS RESET instead of a LUN reset. There is an IOCTL
    >> for using a hierarchical reset (i.e. LUN then TARGET then BUS) but it
    >> must be used by the DSM.
    >>
    >> I have seen Qlogic HBA's send spurious bus and target resets, but not
    >> Emulex. Also, make sure you are using the latest driver supported by
    >> your storage vendor.
    >>
    >> ~kenny
    >>
    >> lec wrote:
    >>> On Jun 5, 10:43 am, lec wrote:
    >>>> Hi, I have a MSCS cluster running FC attached storage. We are using
    >>>> storport because I was under the impression that it did Lun Resets to
    >>>> clear reservations in the event of a path failover ( we are also using
    >>>> MPIO with a Failover Only policy). However when I take a fibre channel
    >>>> trace, I see that in addition to the LUN resets (when the failing path
    >>>> is repaired ) there is also a Target Reset. This is very disruptive,
    >>>> and I cannot tell where this request is coming from. Has anyone seen
    >>>> this behavior? Also do you know of a way to suppress the TRs and to
    >>>> rely only on LR for clearing of reservation conflicts.
    >>>> Any help is most appreciated.
    >>>> Luis
    >>> Sorry, I forgot to fill in some details. I am running win2k3 SP2 and
    >>> currently using emulex LP10000 cards.
    >>> Luis

    >
    > Thanks Kenny. The DSM code does have seem to issue either the
    > IOCTL_STORAGE_BUS_RESET for the win2k case, and the
    > IOCTL_STORAGE_BREAK_RESERVATION for the win2k3 case buy it was my
    > understanding that these were interpreted by the bus driver (MPIO.sys)
    > and that they ( at least I hope the IOCTL_STORAGE_BREAK_RESERVATION )
    > would result on a LUN reset if storport is running.
    >
    > Luis
    >


    The DSM could still be calling IOCTL_STORAGE_BUS_RESET and also don't
    forget a user mode applicatoin can also send a BUS_RESET (i.e. DTM tests
    for WHQL), and if the DSM is not attempting to trap the IOCTL in it's
    DsmCategorizeRequest() routine, then it won't be translated and will be
    sent to the miniport.

    MPIO does not do a translation, it simply calls the DSM and asks if the
    DSM will handle the request or if it should be passed directly to the
    PDO for the physical device (this id is returned by the DSM).

    Which Vendor DSM is this?

  6. Re: Storport & Target Resets

    On Jun 5, 5:52 pm, Kenny Speer wrote:
    > lec wrote:
    > > On Jun 5, 12:23 pm, Kenny Speer wrote:
    > >> Since you are using FCP MPIO, I suggest you contact your MPIO vendor
    > >> (storage vendor). The DSM provided by your vendor could indeed be
    > >> sending a TARGET/BUS RESET instead of a LUN reset. There is an IOCTL
    > >> for using a hierarchical reset (i.e. LUN then TARGET then BUS) but it
    > >> must be used by the DSM.

    >
    > >> I have seen Qlogic HBA's send spurious bus and target resets, but not
    > >> Emulex. Also, make sure you are using the latest driver supported by
    > >> your storage vendor.

    >
    > >> ~kenny

    >
    > >> lec wrote:
    > >>> On Jun 5, 10:43 am, lec wrote:
    > >>>> Hi, I have a MSCS cluster running FC attached storage. We are using
    > >>>> storport because I was under the impression that it did Lun Resets to
    > >>>> clear reservations in the event of a path failover ( we are also using
    > >>>> MPIO with a Failover Only policy). However when I take a fibre channel
    > >>>> trace, I see that in addition to the LUN resets (when the failing path
    > >>>> is repaired ) there is also a Target Reset. This is very disruptive,
    > >>>> and I cannot tell where this request is coming from. Has anyone seen
    > >>>> this behavior? Also do you know of a way to suppress the TRs and to
    > >>>> rely only on LR for clearing of reservation conflicts.
    > >>>> Any help is most appreciated.
    > >>>> Luis
    > >>> Sorry, I forgot to fill in some details. I am running win2k3 SP2 and
    > >>> currently using emulex LP10000 cards.
    > >>> Luis

    >
    > > Thanks Kenny. The DSM code does have seem to issue either the
    > > IOCTL_STORAGE_BUS_RESET for the win2k case, and the
    > > IOCTL_STORAGE_BREAK_RESERVATION for the win2k3 case buy it was my
    > > understanding that these were interpreted by the bus driver (MPIO.sys)
    > > and that they ( at least I hope the IOCTL_STORAGE_BREAK_RESERVATION )
    > > would result on a LUN reset if storport is running.

    >
    > > Luis

    >
    > The DSM could still be calling IOCTL_STORAGE_BUS_RESET and also don't
    > forget a user mode applicatoin can also send a BUS_RESET (i.e. DTM tests
    > for WHQL), and if the DSM is not attempting to trap the IOCTL in it's
    > DsmCategorizeRequest() routine, then it won't be translated and will be
    > sent to the miniport.
    >
    > MPIO does not do a translation, it simply calls the DSM and asks if the
    > DSM will handle the request or if it should be passed directly to the
    > PDO for the physical device (this id is returned by the DSM).
    >
    > Which Vendor DSM is this?


    It is a new DSM. It is being created to support a virtualized storage
    offering.

    Luis


  7. Re: Storport & Target Resets

    ah, well, knowing that, and based on your original question, I suggest
    you handle both IOCTL_STORAGE_RESET_BUS and
    IOCTL_STORAGE_BREAK_RESERVATION within your DSM, and then call your own
    routine which will always perform an IOCTL_STORAGE_BREAK_RESERVATION.

    Now, if you see a LUN_RESET on your target, and you still see a
    RESET_BUS afterward, then you may not be setting the ASC/ASCQ correctly
    on the target. You should be setting 0x2900 (power on, bus reset).

    What is the response to the LUN_RESET and the IO immediately afterward?
    (I assume you see a check condition in your trace with the asc/ascq)

    ~kenny

    lec wrote:
    > On Jun 5, 5:52 pm, Kenny Speer wrote:
    >> lec wrote:
    >>> On Jun 5, 12:23 pm, Kenny Speer wrote:
    >>>> Since you are using FCP MPIO, I suggest you contact your MPIO vendor
    >>>> (storage vendor). The DSM provided by your vendor could indeed be
    >>>> sending a TARGET/BUS RESET instead of a LUN reset. There is an IOCTL
    >>>> for using a hierarchical reset (i.e. LUN then TARGET then BUS) but it
    >>>> must be used by the DSM.
    >>>> I have seen Qlogic HBA's send spurious bus and target resets, but not
    >>>> Emulex. Also, make sure you are using the latest driver supported by
    >>>> your storage vendor.
    >>>> ~kenny
    >>>> lec wrote:
    >>>>> On Jun 5, 10:43 am, lec wrote:
    >>>>>> Hi, I have a MSCS cluster running FC attached storage. We are using
    >>>>>> storport because I was under the impression that it did Lun Resets to
    >>>>>> clear reservations in the event of a path failover ( we are also using
    >>>>>> MPIO with a Failover Only policy). However when I take a fibre channel
    >>>>>> trace, I see that in addition to the LUN resets (when the failing path
    >>>>>> is repaired ) there is also a Target Reset. This is very disruptive,
    >>>>>> and I cannot tell where this request is coming from. Has anyone seen
    >>>>>> this behavior? Also do you know of a way to suppress the TRs and to
    >>>>>> rely only on LR for clearing of reservation conflicts.
    >>>>>> Any help is most appreciated.
    >>>>>> Luis
    >>>>> Sorry, I forgot to fill in some details. I am running win2k3 SP2 and
    >>>>> currently using emulex LP10000 cards.
    >>>>> Luis
    >>> Thanks Kenny. The DSM code does have seem to issue either the
    >>> IOCTL_STORAGE_BUS_RESET for the win2k case, and the
    >>> IOCTL_STORAGE_BREAK_RESERVATION for the win2k3 case buy it was my
    >>> understanding that these were interpreted by the bus driver (MPIO.sys)
    >>> and that they ( at least I hope the IOCTL_STORAGE_BREAK_RESERVATION )
    >>> would result on a LUN reset if storport is running.
    >>> Luis

    >> The DSM could still be calling IOCTL_STORAGE_BUS_RESET and also don't
    >> forget a user mode applicatoin can also send a BUS_RESET (i.e. DTM tests
    >> for WHQL), and if the DSM is not attempting to trap the IOCTL in it's
    >> DsmCategorizeRequest() routine, then it won't be translated and will be
    >> sent to the miniport.
    >>
    >> MPIO does not do a translation, it simply calls the DSM and asks if the
    >> DSM will handle the request or if it should be passed directly to the
    >> PDO for the physical device (this id is returned by the DSM).
    >>
    >> Which Vendor DSM is this?

    >
    > It is a new DSM. It is being created to support a virtualized storage
    > offering.
    >
    > Luis
    >


  8. Re: Storport & Target Resets

    On Jun 5, 10:22 pm, Kenny Speer wrote:
    > ah, well, knowing that, and based on your original question, I suggest
    > you handle both IOCTL_STORAGE_RESET_BUS and
    > IOCTL_STORAGE_BREAK_RESERVATION within your DSM, and then call your own
    > routine which will always perform an IOCTL_STORAGE_BREAK_RESERVATION.
    >
    > Now, if you see a LUN_RESET on your target, and you still see a
    > RESET_BUS afterward, then you may not be setting the ASC/ASCQ correctly
    > on the target. You should be setting 0x2900 (power on, bus reset).
    >
    > What is the response to the LUN_RESET and the IO immediately afterward?
    > (I assume you see a check condition in your trace with the asc/ascq)
    >
    > ~kenny
    >
    > lec wrote:
    > > On Jun 5, 5:52 pm, Kenny Speer wrote:
    > >> lec wrote:
    > >>> On Jun 5, 12:23 pm, Kenny Speer wrote:
    > >>>> Since you are using FCP MPIO, I suggest you contact your MPIO vendor
    > >>>> (storage vendor). The DSM provided by your vendor could indeed be
    > >>>> sending a TARGET/BUS RESET instead of a LUN reset. There is an IOCTL
    > >>>> for using a hierarchical reset (i.e. LUN then TARGET then BUS) but it
    > >>>> must be used by the DSM.
    > >>>> I have seen Qlogic HBA's send spurious bus and target resets, but not
    > >>>> Emulex. Also, make sure you are using the latest driver supported by
    > >>>> your storage vendor.
    > >>>> ~kenny
    > >>>> lec wrote:
    > >>>>> On Jun 5, 10:43 am, lec wrote:
    > >>>>>> Hi, I have a MSCS cluster running FC attached storage. We are using
    > >>>>>> storport because I was under the impression that it did Lun Resets to
    > >>>>>> clear reservations in the event of a path failover ( we are also using
    > >>>>>> MPIO with a Failover Only policy). However when I take a fibre channel
    > >>>>>> trace, I see that in addition to the LUN resets (when the failing path
    > >>>>>> is repaired ) there is also a Target Reset. This is very disruptive,
    > >>>>>> and I cannot tell where this request is coming from. Has anyone seen
    > >>>>>> this behavior? Also do you know of a way to suppress the TRs and to
    > >>>>>> rely only on LR for clearing of reservation conflicts.
    > >>>>>> Any help is most appreciated.
    > >>>>>> Luis
    > >>>>> Sorry, I forgot to fill in some details. I am running win2k3 SP2 and
    > >>>>> currently using emulex LP10000 cards.
    > >>>>> Luis
    > >>> Thanks Kenny. The DSM code does have seem to issue either the
    > >>> IOCTL_STORAGE_BUS_RESET for the win2k case, and the
    > >>> IOCTL_STORAGE_BREAK_RESERVATION for the win2k3 case buy it was my
    > >>> understanding that these were interpreted by the bus driver (MPIO.sys)
    > >>> and that they ( at least I hope the IOCTL_STORAGE_BREAK_RESERVATION )
    > >>> would result on a LUN reset if storport is running.
    > >>> Luis
    > >> The DSM could still be calling IOCTL_STORAGE_BUS_RESET and also don't
    > >> forget a user mode applicatoin can also send a BUS_RESET (i.e. DTM tests
    > >> for WHQL), and if the DSM is not attempting to trap the IOCTL in it's
    > >> DsmCategorizeRequest() routine, then it won't be translated and will be
    > >> sent to the miniport.

    >
    > >> MPIO does not do a translation, it simply calls the DSM and asks if the
    > >> DSM will handle the request or if it should be passed directly to the
    > >> PDO for the physical device (this id is returned by the DSM).

    >
    > >> Which Vendor DSM is this?

    >
    > > It is a new DSM. It is being created to support a virtualized storage
    > > offering.

    >
    > > Luis


    Sorry Kenny, I got caught fighting fires yesterday and was unable to
    respond.
    We do issue the 6/29/0.

    Our problem seems to have been resolved by setting the "TargetOption"
    in the Driver Parameters of the HBA to 1 ( which effectively disables
    it). The documentation is very vague as to what this parameter to 1
    did the trick.

    Thanks for all your help.


    Luis


+ Reply to Thread