IJ22085: RACE BETWEEN AFM FILESET DELETE AND AFM FILESET GETSTATE CAUSES ASSERT

APAR status

• Closed as program error.

Error description

• On one side of an AFM relationship, an AFM fileset is being
  deleted and on the other side there's a getstate to show AFM
  fileset states. The getstate command picks the fileset being
  deleted to print its stats, and causes the Assert.
  

Local fix

• Do not run "mmafmctl <fs> getstate/mmdiag" commands when
  AFM filesets are being Deleted.
  

Problem summary

• On one side of an AFM relationship, an AFM fileset is being
  deleted and on the other side there's a getstate to show AFM
  fileset states. The getstate command picks the fileset being
  deleted to print its stats, and causes the Assert.
  

Problem conclusion

• Benefits of the solution:
  
  
  Avoid hitting the assertion on the AFM filesets getstate running
  node,  when AFM fileset(s) are being Deleted.
  
  Work around:
  
  Do not run "mmafmctl <fs> getstate/mmdiag" commands when
  AFM filesets are being Deleted.
  
  Problem trigger:
  
  On one side an AFM fileset is being deleted (which could take
  time depending on number of inodes in the fileset and amount of
  data).  While this is happening, another node in the cluster
  queries AFM stats on the AFM filesets (mmafmctl <fs> getstate
  (or) an mmdiag running).
  
  Symptom:
  
  Abend/Crash
  
  Platforms affected:
  
  ALL Linux and AIX environments.
  
  Functional Area affected:
  
  AFM
  
  Customer Impact:
  
   High
  

Temporary fix

Comments

APAR Information

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

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

Fix information

• Fixed component name

  GPFS NR POWER E

• Fixed component ID

  5725Q01NP

Applicable component levels