AIX

AIX

Connect with fellow AIX users and experts to gain knowledge, share insights, and solve problems.

 View Only
  • 1.  The behavior with nMPIO when one path down

    Posted Thu November 15, 2018 10:56 PM

    Originally posted by: lylklb


    This might be a historical and recessive problem in AIX(5/6/7) nMPIO , that is, when one of the multipath links broken/failed, all the other good links' I/O would also together hang up for a short time (15~30s)! So how to resolve such problem?

    Notes: This should be nothing to do with the attributes of fscsi/hdisk because we have already set up for dyntrk=yes & fc_err_recov=fast_fail with fscsi and round-robin with nMPIO.



  • 2.  Re: The behavior with nMPIO when one path down

    Posted Sun November 18, 2018 05:23 PM


  • 3.  Re: The behavior with nMPIO when one path down

    Posted Mon November 19, 2018 09:06 PM

    Originally posted by: lylklb


    I don't think that the two following doc reference could explain why the I/O stream of all the other good links would hang up for a short time(15~30s) when one path was down!


    If a path fails or is disabled, it is no longer used for sending I/O. The priority of the remaining paths is then recalculated to determine the percentage of I/O that should be sent down each path. If all paths have the same path_priority value, the PCM attempts to equally distribute I/O across all enabled paths.


    All the MPIO paths that use the failed component indicate a Failed state, and error log entries are created against that component, and the MPIO software ceases using the failed paths for user I/O.

     



  • 4.  Re: The behavior with nMPIO when one path down

    Posted Mon November 19, 2018 10:43 PM

    Originally posted by: Chris Gibson


    It sounds like the behaviour you are experiencing is not expected or correct. I would recommend you open a case with IBM support for investigation.



  • 5.  Re: The behavior with nMPIO when one path down

    Posted Tue November 20, 2018 01:57 AM

    Originally posted by: lylklb


    In fact,  this is a common and underlying problem,  not a special issue!

     

    Referring to the following similar case links:
    https://community.emc.com/thread/117936?start=0