Stopping zFS

In general, do not stop zFS. Stopping zFS is disruptive to applications that are using zFS file systems. zFS stops automatically when you shut down z/OS® UNIX. To shut down an LPAR or to re-IPL an LPAR, use the MODIFY OMVS,SHUTDOWN operator command to shut down z/OS UNIX. This action synchronizes data to the file systems and unmounts or moves ownership in a shared file system environment. A planned system shutdown must include the unmount or move of all owned file systems and the shut down of zFS. The MODIFY OMVS,SHUTDOWN command unmounts and moves the owned file systems and shuts down zFS. For shutdown procedures using F OMVS,SHUTDOWN, see the topic on Planned shutdowns using F OMVS,SHUTDOWN in z/OS UNIX System Services Planning.

zFS can be stopped using the MODIFY OMVS,STOPPFS=ZFS operator command. Automatic ownership movement can occur for both the z/OS UNIX owner and the zFS owner. See z/OS UNIX System Services Planning for information about the various automove settings for z/OS UNIX file system ownership. zFS aggregate ownership will move unless the file system is unmounted by z/OS UNIX. zFS file systems that become unmounted will need to be mounted again after zFS is restarted.

When zFS is stopped, you receive the following message (after replying Y to message BPXI078D):

nn BPXF032D FILESYSTYPE ZFS TERMINATED. REPLY ’R’ WHEN READY TO RESTART. REPLY ’I’ TO IGNORE.

When an LPAR is shut down without the orderly shutdown of zFS, it is likely that recovery actions (automatic recovery on the next mount; if the mount fails, it might be necessary to manually run salvager) will be necessary to bring zFS aggregates back to a consistent state. In addition, some file activity can be lost.

To restart zFS, reply r to message nn. (For example, r 1,r). If you want zFS to remain stopped, you can reply i to remove the prompt. In this case, zFS can be redefined at a later time using the SETOMVS RESET=(xx)operator command. However, this can result in zFS file systems becoming NOT ACTIVE. An unmount and remount is required to activate a file system that is NOT ACTIVE. If you plan to restart zFS, you should reply r to the message.

Note: Stopping zFS can have shared file system (sysplex) implications. See Using zFS in a shared file system environment for information about shared file systems.

If the zFS colony address space has an internal failure, it typically does not terminate. It might disable an aggregate (see Diagnosing disabled aggregates). If it is a case where it does terminate, normally the zFS colony address space will restart automatically. Otherwise, message BPXF032D (the same message you receive when the MODIFY OMVS,STOPPFS=ZFS operator command is used) is issued and a reply is requested.

On z/OS V1R13 and later systems, if an internal problem occurs, zFS attempts an internal restart. It internally remounts any zFS file systems that were locally mounted, without requiring any support from z/OS UNIX. The zFS ownership for aggregates that are owned on the system that is internally restarted might be moved (by zFS for sysplex-aware file systems) to another system. For more information, refer to Step 10.

If zFS is running on a z/OS V1R12 or earlier system and terminates abnormally, automatic ownership movement occurs for both the z/OS UNIX owner and the zFS owner, if possible. See z/OS UNIX System Services Planning for information about z/OS UNIX file system ownership for the various automove settings. zFS aggregate ownership moves unless the file system is unmounted by z/OS UNIX. Applications with an open file on these file systems receive I/O errors until the file is closed. After zFS is restarted, the operator must remount any file systems that were locally mounted (that is, file systems that were owned by that system and were not moved). This can be done by using the MODIFY BPXOINIT,FILESYS=REINIT operator command. This causes a remount for each file system that was mounted through a BPXPRMxx parmlib statement.