IV19684: UNNECESSARY SYNCVG TRIGGERED FOR ECM VGS WITH PASSIVE MWCC APPLIES TO AIX 6100-07

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Customer is using Enhanced Concurrent Mode
  (ECM) VGs and passive MWCC for all shared LVs
  in the cluster.
  
  The secondary (passive) node has been rebooted
  while the primary node remained active.
  
  Afterwards a RG has been moved to the secondary
  node. The primary node unmounted the file systems
  and switched VGs to passive mode. So the LVs are
  in sync. The secondary node switches VGs to active
  mode.
  
  In the above described scenario  HA triggered
  syncvg which is not necessary (the LVs are in
  sync).
  
  Due to passive MWCC all LPs got syncd which had
  a negative impact on IO performance and the RG
  could not be moved until syncvg completed, because
  LVs are in open state.
  

Local fix

Problem summary

• If a concurrent VG with passive MWC LVs is varied on (in
  passive mode) on the standby node, while the VG is online with
  filesystems mounted on the active node, then it will flag all
  of the passive MWC LVs as needing recovery, just as if it was
  recoverying from a crash.
  This state will persist even when the standby node becomes
  active and the VG becomes active on that node.
  Even if the filesystems were unmounted cleanly on the active
  node prior to moving to the standby node.
  .
  HA calls syncvg after moving VG to the other node, and since
  the LVs are all marked as needing recovery, they all get
  completely force resync'd.
  .
  This extra resync I/O causes unnecessary I/O overhead. for that
  VG and can have noticable impact on I/O performance.
  

Problem conclusion

• Add logic to LVM to re-assess LV state when switching from
  concurrent passive to active mode.  This will update the
  standby node to know that the filesystems were unmounted
  gracefully on the primary node and that no recovery is needed.
  .
  If there was actually a crash of the primary node, then
  recovery would still be done.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

  IV11864

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  AIX 610 STD EDI

• Fixed component ID

  5765G6200

Applicable component levels

• R610 PSY U848592

     UP12/07/16 I 1000

PTF to Fileset Mapping

• U848592 bos.rte.lvm 6.1.7.16