MPIO path removal control - Storage

This is a discussion on MPIO path removal control - Storage ; Hi All, I am working on a DSM driver and I encountered problem to control MPIO path removal from driver in question. MPIO seems to ignore retry setting in DsmInterpretError() when it comes to path removal (i.e. disconnected). I also ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: MPIO path removal control

  1. MPIO path removal control

    Hi All,

    I am working on a DSM driver and I encountered problem to control MPIO path
    removal from driver in question. MPIO seems to ignore retry setting in
    DsmInterpretError() when it comes to path removal (i.e. disconnected). I
    also tried to return FAIL status in DsmRemoveDevice()/DsmRemovePath()
    functions but MPIO seems to ignore them and removes structures anyway.
    Ofcourse I understand that my code might be incorrect.
    Is it possible to delay path removal in MPIO from DSM driver level? If so
    then could you give me a hint on how to do it?

    Best regards,
    Tomasz Kantecki



  2. Re: MPIO path removal control

    As far as I know, you cannot *trick* MPIO into ignoring IRP_MN_REMOVE_DEVICE
    which is what you want to do. When PnP attempts to remove the device, you
    should not attempt to stop it.

    When MPIO calls DsmRemovePending() you should do all the cleanup you require
    and track the fact that the device (i.e. path) is about to be removed. Then
    when DsmRemoveDevice() is called, you need to cleanup and remove the
    structures within your DSM since it no longer exists, even if you think it
    does.

    Now, what do you mean by "disconnected" below? Are you referring to
    physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?

    What is the actual problem you want to resolve? (i.e. why do you want to
    delay the removal of the device?)

    ~kenny

    "Tomasz Kantecki" wrote in message
    news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
    > Hi All,
    >
    > I am working on a DSM driver and I encountered problem to control MPIO
    > path removal from driver in question. MPIO seems to ignore retry setting
    > in DsmInterpretError() when it comes to path removal (i.e. disconnected).
    > I also tried to return FAIL status in DsmRemoveDevice()/DsmRemovePath()
    > functions but MPIO seems to ignore them and removes structures anyway.
    > Ofcourse I understand that my code might be incorrect.
    > Is it possible to delay path removal in MPIO from DSM driver level? If so
    > then could you give me a hint on how to do it?
    >
    > Best regards,
    > Tomasz Kantecki
    >
    >



  3. Re: MPIO path removal control

    Thanks for the answer.

    I think the best way would be to describe desired functionality of my MPIO
    driver:
    - failover ASAP when some other paths are available
    - wait some time before removing device when there is the only path left to
    the device

    I need this functionality as it happens with some FC cards that link may
    reset itself in certain circumstances. When it happens and this is the only
    path I might loose all devices. So all I want to do is to make MPIO more
    tolerant and wait 20 seconds longer until link is up again. If it is not up
    then it should proceed with adequate actions as it usually does.

    I made some tests with MPIO and I found out one way to stop MPIO from
    removing device for some time - it some kind of active wait in the driver.
    Yet this solution is very awkward and may affect other threads&drivers in
    the system. I need something better than this.

    Regards
    Tomasz


    "Kenny Speer" wrote in message
    news:545CCE5F-21EC-42CA-A64C-D952EB4AE2EA@microsoft.com...
    > As far as I know, you cannot *trick* MPIO into ignoring
    > IRP_MN_REMOVE_DEVICE which is what you want to do. When PnP attempts to
    > remove the device, you should not attempt to stop it.
    >
    > When MPIO calls DsmRemovePending() you should do all the cleanup you
    > require and track the fact that the device (i.e. path) is about to be
    > removed. Then when DsmRemoveDevice() is called, you need to cleanup and
    > remove the structures within your DSM since it no longer exists, even if
    > you think it does.
    >
    > Now, what do you mean by "disconnected" below? Are you referring to
    > physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?
    >
    > What is the actual problem you want to resolve? (i.e. why do you want to
    > delay the removal of the device?)
    >
    > ~kenny
    >
    > "Tomasz Kantecki" wrote in message
    > news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
    >> Hi All,
    >>
    >> I am working on a DSM driver and I encountered problem to control MPIO
    >> path removal from driver in question. MPIO seems to ignore retry setting
    >> in DsmInterpretError() when it comes to path removal (i.e. disconnected).
    >> I also tried to return FAIL status in DsmRemoveDevice()/DsmRemovePath()
    >> functions but MPIO seems to ignore them and removes structures anyway.
    >> Ofcourse I understand that my code might be incorrect.
    >> Is it possible to delay path removal in MPIO from DSM driver level? If so
    >> then could you give me a hint on how to do it?
    >>
    >> Best regards,
    >> Tomasz Kantecki
    >>
    >>

    >




  4. Re: MPIO path removal control

    I see, but MPIO PDORemovePeriod is designed to handle this situation. You
    are allowed to lose all paths to a device and the PseudoLUN will not be
    destroyed until the expiration of PDORemovePeriod. You can simply increase
    this to 60 seconds or so and you have that amount of time for a path to
    arrive before your IO errors or the PDO is removed.

    Also, you can change the LinkTimeout on the HBA to be the amount of time you
    need. At the expiration of LinkTimeout the miniport will respond with
    SELECTION_TIMEOUT and then PnP will attempt to remove the devices.

    I don't recommend sleeping the thread or stalling the processor to your
    20sec wait. I suppose you could also be sitting in an idle loop for 20 sec
    before returning, but it seems that would cause you alot more pain than it's
    worse.

    Feel free to ping me offline if you like.

    ~kenny

    "Tomasz Kantecki" wrote in message
    news:udF$1p$tHHA.4916@TK2MSFTNGP04.phx.gbl...
    > Thanks for the answer.
    >
    > I think the best way would be to describe desired functionality of my MPIO
    > driver:
    > - failover ASAP when some other paths are available
    > - wait some time before removing device when there is the only path left
    > to the device
    >
    > I need this functionality as it happens with some FC cards that link may
    > reset itself in certain circumstances. When it happens and this is the
    > only path I might loose all devices. So all I want to do is to make MPIO
    > more tolerant and wait 20 seconds longer until link is up again. If it is
    > not up then it should proceed with adequate actions as it usually does.
    >
    > I made some tests with MPIO and I found out one way to stop MPIO from
    > removing device for some time - it some kind of active wait in the driver.
    > Yet this solution is very awkward and may affect other threads&drivers in
    > the system. I need something better than this.
    >
    > Regards
    > Tomasz
    >
    >
    > "Kenny Speer" wrote in message
    > news:545CCE5F-21EC-42CA-A64C-D952EB4AE2EA@microsoft.com...
    >> As far as I know, you cannot *trick* MPIO into ignoring
    >> IRP_MN_REMOVE_DEVICE which is what you want to do. When PnP attempts to
    >> remove the device, you should not attempt to stop it.
    >>
    >> When MPIO calls DsmRemovePending() you should do all the cleanup you
    >> require and track the fact that the device (i.e. path) is about to be
    >> removed. Then when DsmRemoveDevice() is called, you need to cleanup and
    >> remove the structures within your DSM since it no longer exists, even if
    >> you think it does.
    >>
    >> Now, what do you mean by "disconnected" below? Are you referring to
    >> physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?
    >>
    >> What is the actual problem you want to resolve? (i.e. why do you want to
    >> delay the removal of the device?)
    >>
    >> ~kenny
    >>
    >> "Tomasz Kantecki" wrote in message
    >> news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
    >>> Hi All,
    >>>
    >>> I am working on a DSM driver and I encountered problem to control MPIO
    >>> path removal from driver in question. MPIO seems to ignore retry setting
    >>> in DsmInterpretError() when it comes to path removal (i.e.
    >>> disconnected). I also tried to return FAIL status in
    >>> DsmRemoveDevice()/DsmRemovePath() functions but MPIO seems to ignore
    >>> them and removes structures anyway. Ofcourse I understand that my code
    >>> might be incorrect.
    >>> Is it possible to delay path removal in MPIO from DSM driver level? If
    >>> so then could you give me a hint on how to do it?
    >>>
    >>> Best regards,
    >>> Tomasz Kantecki
    >>>
    >>>

    >>

    >
    >



  5. Re: MPIO path removal control

    Tried to reply to you, but your mail server bounced my gmail account.

    "Tomasz Kantecki" wrote in message
    news:udF$1p$tHHA.4916@TK2MSFTNGP04.phx.gbl...
    > Thanks for the answer.
    >
    > I think the best way would be to describe desired functionality of my MPIO
    > driver:
    > - failover ASAP when some other paths are available
    > - wait some time before removing device when there is the only path left
    > to the device
    >
    > I need this functionality as it happens with some FC cards that link may
    > reset itself in certain circumstances. When it happens and this is the
    > only path I might loose all devices. So all I want to do is to make MPIO
    > more tolerant and wait 20 seconds longer until link is up again. If it is
    > not up then it should proceed with adequate actions as it usually does.
    >
    > I made some tests with MPIO and I found out one way to stop MPIO from
    > removing device for some time - it some kind of active wait in the driver.
    > Yet this solution is very awkward and may affect other threads&drivers in
    > the system. I need something better than this.
    >
    > Regards
    > Tomasz
    >
    >
    > "Kenny Speer" wrote in message
    > news:545CCE5F-21EC-42CA-A64C-D952EB4AE2EA@microsoft.com...
    >> As far as I know, you cannot *trick* MPIO into ignoring
    >> IRP_MN_REMOVE_DEVICE which is what you want to do. When PnP attempts to
    >> remove the device, you should not attempt to stop it.
    >>
    >> When MPIO calls DsmRemovePending() you should do all the cleanup you
    >> require and track the fact that the device (i.e. path) is about to be
    >> removed. Then when DsmRemoveDevice() is called, you need to cleanup and
    >> remove the structures within your DSM since it no longer exists, even if
    >> you think it does.
    >>
    >> Now, what do you mean by "disconnected" below? Are you referring to
    >> physically disconnected or NT_STATUS DEVICE_NOT_CONNECTED (0xc000009d)?
    >>
    >> What is the actual problem you want to resolve? (i.e. why do you want to
    >> delay the removal of the device?)
    >>
    >> ~kenny
    >>
    >> "Tomasz Kantecki" wrote in message
    >> news:%23NUdSmmsHHA.3400@TK2MSFTNGP03.phx.gbl...
    >>> Hi All,
    >>>
    >>> I am working on a DSM driver and I encountered problem to control MPIO
    >>> path removal from driver in question. MPIO seems to ignore retry setting
    >>> in DsmInterpretError() when it comes to path removal (i.e.
    >>> disconnected). I also tried to return FAIL status in
    >>> DsmRemoveDevice()/DsmRemovePath() functions but MPIO seems to ignore
    >>> them and removes structures anyway. Ofcourse I understand that my code
    >>> might be incorrect.
    >>> Is it possible to delay path removal in MPIO from DSM driver level? If
    >>> so then could you give me a hint on how to do it?
    >>>
    >>> Best regards,
    >>> Tomasz Kantecki
    >>>
    >>>

    >>

    >
    >



+ Reply to Thread