Dynamic movement of the zFS owner

For zFS read/write sysplex-aware file systems, an important aspect of performance is knowing which system is the zFS owner. The zFS owner is the system that handles metadata updates to the file system. zFS automatically moves the zFS owner among zFS systems, based on the amount of activity at the zFS owner from each system. The frequency of the dynamic ownership movement varies, depending on the zFS level. Ownership moves less often than on systems that are running previous levels of the z/OS® system. File requests do not fail as a result of dynamic aggregate movement. New requests are suspended until the aggregate is moved and then requests are allowed to complete. The system produces the following messages, for example:

Source system
22.19.12 DCEIMGVN IOEZ00548I Requesting that DCEIMGVM takeover aggregate PLEX.JMS.AGGR006.LDS0006 LDS0006 
(requests: local 2, new owner 1202 total 1204 

Target system
22.19.12 DCEIMGVM IOEZ00388I Aggregate takeover being attempted for aggregate PLEX.JMS.AGGR006.LDS0006 
22.19.12 DCEIMGVM IOEZ00044I Aggregate PLEX.JMS.AGGR006.LDS0006 attached successfully.

In message IOEZ00548I, local requests is the number of requests on the source system during the measurement period. New owner requests is the number of requests from the target system during the measurement period. Total requests is the total number of requests from all systems during the measurement period. (Total requests can be greater than the sum of the local requests and the new owner requests). This information is provided to aid in problem determination.

For zFS sysplex-aware file systems, zFS aggregate movement is independent of z/OS UNIX ownership movement except for the cases that are discussed later in this section. When z/OS UNIX ownership movement occurs because of the mount AUTOMOVE specification (for example, AUTOMOVE or AUTOMOVE(INCLUDE,SY1,SY2) or AUTOMOVE(EXCLUDE,SY1,SY2)), the z/OS UNIX ownership movement is as expected. Because z/OS UNIX sends requests directly to the local zFS system, the z/OS UNIX ownership movement does not change the way that the zFS aggregate is accessed. z/OS UNIX ownership movement between zFS sysplex-aware file systems that have local mounts does not change how the file system is accessed.

Certain z/OS UNIX automove settings will change file system access.

If the NOAUTOMOVE setting is used, the file system is made unavailable. In other words, the file system becomes unowned. In that situation, z/OS UNIX denies requests for file access.
If the UNMOUNT setting is used, the file system is unmounted across the sysplex. Any file access will occur on the underlying file system.

Tip: Mount system-specific zFS file systems with the UNMOUNT setting instead of the NOAUTOMOVE setting.

Remember the following facts about the relationship between z/OS UNIX ownership movement and zFS aggregate ownership movement:

z/OS UNIX controls whether any access exists at all.
zFS ownership controls which system updates the metadata.

If a zFS read/write file system is non-sysplex aware, then z/OS UNIX controls movement of zFS read/write mounted file systems as in prior releases for a shared file system environment and the z/OS UNIX owner and the zFS owner are always the same.

For zFS read/write sysplex-aware file systems, zFS ownership can be moved dynamically in three situations:

For performance reasons,
When zFS or z/OS UNIX is shut down, or
When a system outage exists that was caused by an abnormal shutdown or an internal restart of zFS. An abnormal shutdown occurs if, for example, zFS is canceled or if zFS abends.

For systems that are z/OS V2R3 or later, and any prior release system that has honor_syslist=on, zFS takes the z/OS UNIX automove options into consideration when determining whether to move zFS ownership. If zFS ownership is to be moved, the z/OS UNIX automove system lists are used to determine which systems are eligible to become the new zFS owner. For more information about system lists, see Using system lists in z/OS UNIX System Services Planning.

Tip: In order for the z/OS UNIX automove options to be used consistently throughout the entire sysplex, each system in the sysplex is required to have honor_syslist=on or be at least at the V2R3 level.

When all systems in the sysplex are release z/OS V2R3 or later, or a prior release with honor_syslist=on, zFS will not move ownership of read/write sysplex-aware file systems that have z/OS UNIX automove options UNMOUNT or NOAUTOMOVE. It also will not move ownership to systems that are excluded by a z/OS UNIX automove system list. zFS ownership will move only to systems that are included by a z/OS UNIX automove system list. z/OS UNIX uses the list of included systems, as determined by the automove system list, as a priority ordered list. zFS considers the list as a list of eligible systems with no priority given to any system based on its order in the list. The automove INCLUDE system list can also have a wildcard (*) in it. In that situation, from the zFS viewpoint, any system with a local mount is eligible to become the new zFS owner. Again, from the zFS viewpoint, the absence of a z/OS UNIX automove system list also means that any system with a local mount is eligible to become the new zFS owner.

When all systems in the sysplex are at release z/OS V2R3 or later, or at a prior release with honor_syslist=on, you can create subgroups of systems that own specific zFS read/write sysplex-aware file systems by including the members of the subgroup of systems in a z/OS UNIX automove INCLUDE system list. You can also prevent systems from becoming the zFS owner of certain file systems by using a z/OS UNIX automove EXCLUDE system list. To keep zFS ownership of a specific file system on a specific system, use the z/OS UNIX automove option NOAUTOMOVE, UNMOUNT, or a system INCLUDE list with that one system name specified in it.

Start of change Additionally, when movement is occurring for performance reasons, zFS-owning systems that are at the V2R4 level or at the V2R3 level with APAR OA56145 applied, will only move ownership to other V2R4 systems or V2R3 systems that have APAR OA56145 applied. End of change

Start of change When movement is occurring because zFS or z/OS UNIX is being shut down, zFS-owning systems that are at the V2R4 level or at the V2R3 level with APAR OA56145 applied, will first attempt to move ownership to other V2R4 systems or V2R3 systems that have APAR OA56145 applied, as previously described. If no eligible system is found that is at the V2R4 level or at the level with APAR OA56145, ownership can move to any other eligible system in the sysplex. End of change