Unmounting zFS file systems before copying or moving

When a user mounts (attaches) an aggregate to a particular system, zFS records the name of the system, the sysplex name (when it is a sysplex), and a time stamp in the zFS aggregate (in block zero of the aggregate). In addition, while the aggregate is mounted, zFS updates the time stamp every 30 seconds. If another system (that is not in the same sysplex) sharing the DASD attempts to mount the same aggregate, zFS on that system recognizes that the system name in the aggregate is not blank and does not match this system. In this case, zFS waits 65 seconds to see if the time stamp is updated (by the original system). If the time stamp is updated in that 65-second period, zFS refuses to mount the aggregate and returns ENXIO (X'8A') with reason code EF096058. As a result, zFS prevents a system from writing to a zFS aggregate that is mounted read/write on another system. If the time stamp is not updated, the mount succeeds after waiting for 65 seconds. A similar situation might occur when a copy was made of a zFS aggregate, or an entire DASD volume, while the zFS aggregates were mounted. In this case, when a mount is attempted of these copies, a 65-second block zero wait might be seen for each mount. This will be accompanied by an IOEZ00807I message that is issued by zFS.

When a zFS aggregate is unmounted (detached), the system name and the time stamp are cleared. In this case, the next mount does not wait because zFS knows that the aggregate is not currently mounted. If the aggregate is being mounted on a different member in the same sysplex after a failure, zFS does not wait because it recognizes that this is a different system that is in the same sysplex.

As a result, you can cause zFS to wait during mount unnecessarily and you can experience z/OS® UNIX latch contention if you fail to unmount (detach) a zFS aggregate before copying it or moving it to another system.