IV87632: THE CHANGED DATA DOESN'T FLUSH TO DISK IN TIME WHEN USE MMAP.

APAR status

• Closed as program error.

Error description

• User can only see the updated data after call sync or
  wait
  a couple of seconds when use mmap().
  

Local fix

Problem summary

• The customer compiles his ocaml program on RH6.x and
  copy the target binary after compiler is done, but he
  always got all-zero files. The reason is ocaml calls
  fallocate() to allocate file blocks. Under 2.6.x kernel,
  the fallocate operation belongs to inode_operations.
  So gpfs has to open instance by GetNFS. GPFS calls
  terminateMmap only after the last open instance is
  closed.
  As nfs open instance has delay close semantics that
  makes terminateMmap call is delayed too. BTW, RH7.x
  has no such problem, because fallocate() belongs to
  file_operations on that kernel. Ext3 file system has
  no such problem too as its mmap/regular read write
  using unique page cache.
  

Problem conclusion

• The posix standard is ambiguous about if shared
  memory mapping should be flushed to disk at munmap()
  time, it says nothing about it. msync() is used to
  flush modified memory mapping, and gpfs support it
  well. Linux msync(2) manual seems to imply munmap
  will flush the dirty data, though it does not say
  that in munmap(2).
  man msync(2)
         msync() flushes changes made to the in-core
         copy of a file that was mapped into memory
         using mmap(2) back to the filesystem.  Without
         use of this call, there is no guarantee that
         changes are written back before munmap(2) is
         called.
  
  Though the standard is ambiguous, the customer's
  expection (get up to date binary when compiler is
  done) sounds reasonable.
  
  This fix flushes memory mapping when last write mapping
  is gone. It will be better if we can flush memory mapping
  for every munmap(), but we don't do that as that may
  affect performance too much.
  

Temporary fix

Comments

APAR Information

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

  IV84537

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

Fix information

• Fixed component name

  SPECTRUM SCALE

• Fixed component ID

  5725Q01AP

Applicable component levels

• R421 PSY U875009

     16/11/11 I 1000