Migrate from HFS file systems to zFS file systems

Description

Before z/OS® V1R7, the HFS file system was the primary hierarchical file system. As of z/OS V1R7, you can use any combination of HFS and zFS file systems. Because zFS has higher performance characteristics than HFS and is the strategic file system, you should migrate your HFS file systems to zFS.

The HFS and zFS file system types in mount statements and command operands are now generic file system types that can mean either HFS or zFS. Based on the data set type, the system will determine which is appropriate. But note that you must still specify a type (HFS or zFS and it cannot be defaulted), and if the type you specify is not correct for the file system being mounted, any associated parameter string setting in the mount statement or command is ignored, even though the system sets the type correctly and processes the mount.

Table 1 provides more details about this migration action. Use this information to plan your changes to the system.

Table 1. Information about this migration action
Element or feature: z/OS UNIX.
When change was introduced: z/OS Distributed File Service zFS became the strategic file system in z/OS V1R7.
Applies to migration from: z/OS V2R1 and z/OS V1R13.
Timing: Before installing z/OS V2R2.
Is the migration action required?

No, but recommended because the action is planned to become a requirement in a future release. zFS is the strategic file system for z/OS UNIX and continues to be enhanced to provide superior performance, reliability, and data integrity.

z/OS V2R2 supports HFS file systems.
Target system hardware requirements: None.
Target system software requirements: None.
Other system (coexistence or fallback) requirements: None.
Restrictions:
  • Understand the zFS recommendations and limits. For more information, see "Minimum and maximum file sizes" in z/OS Distributed File Service zFS Administration
  • The DDNAME() keyword of the BPXPRMxx ROOT and MOUNT statements is not supported by zFS. Use the FILESYSTEM(name) keyword instead.
System impacts: None.
Related IBM® Health Checker for z/OS check: Use check USS_HFS_DETECTED to verify all file systems mounted. This check issues exception message BPXH068E if any HFS file systems are found.

Steps to take

Follow these steps:
  1. Before beginning the migration, do the following:
    • Ensure that the PTF for APAR OA46639 is installed on your system. This APAR corrects a problem that can occur when socket type files are copied.
    • Establish backout procedures.
    • Decide on naming conventions.
    • Decide on unavailability.
    • Understand any cloning or deployment changes required by zFS systems being linear data sets. Considerations would include any copy utility invocations, BPXPRMxx specifications for symbolics, and placement of zFS file systems on system volumes.
  2. Perform the conversion from an HFS to zFS file system.
    You can use the BPXWH2Z tool to perform the conversion. It is an ISPF-based tool that migrates HFS file systems to zFS file systems. Using its panel interface, you can alter the space allocation, placement, SMS classes, and data set names. A HELP panel is provided. With this tool, you can:
    • Migrate HFS file systems (both mounted and unmounted) to zFS file systems. If the HFS being migrated is mounted, the tool automatically unmounts it and then mounts the new zFS file system on its current mount point.
    • Define zFS aggregates by default to be approximately the same size as the HFS. The new allocation size can also be increased or decreased. In z/OS V1R13, ZFS could require up to four times (4X) the space that HFS did; therefore, for z/OS V2R1 be sure to allocate more space. See zFS: Accommodate new DASD space requirements.
    • Have the migration run in TSO/E foreground or UNIX background.

    You can use the JCL sample ISPBTCH in SYS1.SAMPLIB to invoke BPXWH2Z as an ISPF batch job. Before you run the job, read the Notes section. When you run BPXWH2Z on your z/OS system, make sure it uses that same z/OS level of the pax command. You can manually migrate from an HFS to zFS file system without using the tool. However, you would need to allocate and format the target zFS file systems.

    You can use the JCL sample ISPBTCH in SYS1.SAMPLIB to invoke BPXWH2Z as an ISPF batch job. Before you run the job, read the notes section. When you run BPXWH2Z on your z/OS V1R13 system, it uses the z/OS V1R13 level of the pax command. This level was enhanced in z/OS V1R7 for sparse file support and other characteristics that are of concern when migrating from an HFS to zFS file system. You can manually migrate from an HFS to zFS file system without using the tool. However, you would need to allocate and format the target zFS file systems.

    Requirement: The BPXWH2Z tool requires the zFS address space to be operational. Therefore, before attempting to migrate existing HFS to zFS file systems using BPXWH2Z, make sure that the zFS address space has been successfully configured and initialized.

    Tip: You can dynamically migrate the HFS sysplex root in a shared file system configuration to zFS while the root is in use, without disrupting workloads. Although the shared file system configuration is required, the sysplex can be a single system. For the steps involved in migrating the sysplex root file system from HFS to zFS, see "Migrating the sysplex root file system from HFS to zFS after IPLing z/OS V1R12".
  3. Change policies and scripts, and so forth, to reflect the change from the HFS file system to zFS file system. Use the RMF Monitor III option to report on zFS activity. Refer to migration action "Monitor the zFS file system activity" for information on gathering zFS activity in RMF Monitor III.
    Tip: Use the RMF Monitor III option to report on zFS activity.
  4. The DDNAME(name) keyword of the BPXPRMxx ROOT and MOUNT statements is not supported by zFS. If you use them. change these statements to use the FILESYSTEM(name) keyword instead.

Migrating the sysplex root file system from HFS to zFS after IPLing your previous z/OS system:

Before you begin the migration:
  • Ensure that the following requirements have been met:
    • All systems in the sysplex are at the V1R12 level.
    • The current sysplex root file system PFS, and the new sysplex root file system PFS, are up in all the systems in shared file system configuration.
  • Be aware of the following restrictions:
    • The current sysplex root file system must be mounted as a read-only file system.
    • The systems that do not meet the requirements for this migration action cannot join the sysplex during the sysplex root file system migration processing, but they can join the sysplex after the sysplex root migration has completed.
    • The current sysplex root and the new sysplex root must be either HFS or zFS in any combination. If the new sysplex root is zFS, then it must be HFS-compatible.
    • The sysplex root or any directories on it cannot have been exported by the DFS or SMB server.
  • Note the following:
    • Remote NFS mounts of the sysplex root or any directories on it are considered active use of the current sysplex root file system.
    • During the migration, the new zFS sysplex root file system must not be HSM-migrated, mounted, or in use.
    • Mount parameters are preserved during the migration or replacement of the sysplex root file system of the same file system type (PFS). They are dropped if the file system type is different.
    • Directories, data, files, and links are not copied from one file system to another.

Perform the migration as follows:

  1. Ensure that a file system has been mounted read-only as the current sysplex root file system. When the root is mounted read-only, there are no function-shipping clients as long as physical paths to the DASD are available to each system. To verify that there are no function-shipping clients, issue: 
    D OMVS,F,NAME=root_file_system_name
    You should see CLIENT=N on each system.
  2. Allocate and set up the new zFS sysplex root file system:
    1. Create a new zFS file system to be used as the new sysplex root file system. z/OS Distributed File Service zFS Administration discusses creating and managing zFS file systems.
      Rules:
      • The UID, GID and the permission bits of the root directory in the new sysplex root file system must be same as the root directory in the current sysplex root file system.
      • If the SECLABEL class is active and the MLFSOBJ option is active, the security label for the new zFS file system must match the assumed security label of the current sysplex root file system.
    2. On the new sysplex root file system, set up the active mount points and the symbolic links. The mount points and symbolic links must be the same as the ones on the current sysplex root file system. You can set them up either (1) manually or (2) by using the pax shell command to populate the new sysplex root file system using the existing sysplex root as a source. To do it manually, create a mount point in the existing sysplex root (for example, /newroot) and mount the new sysplex root file system in the MODE(RDWR) on that mount point. After mounting the new sysplex root file system, manually issue MKDIRs and ln -s to create the mount point directories and symbolic links similar to the existing sysplex root file system. Note that the new sysplex root file system must contain all active mount points and symbolic links exactly as on the existing sysplex root file system.
    3. Use the pax shell command to populate the new file system, using the existing sysplex root as a source.
      Example: 
      cd /
pax -wr -pe -XCM ./ /newroot
      For more information about using pax to copy data from an HFS file system to a zFS file system, see z/OS Distributed File Service zFS Administration.
    4. Unmount the new zFS file system.
  3. On any system in the shared file system configuration, issue: 
    F OMVS,NEWROOT=new.root.file.system.name,COND=<Yes|No>
    YES
    Proceed conditionally. The system checks for active usage in the current sysplex root file system and reports the active usage in a BPXF245I message. If file activity is found, the command fails with EBUSY return code and JrActivityFound reason code. If file activity is not found, the command continues processing to replace the sysplex root. YES is the default.
    NO
    Proceed unconditionally. The system checks for active usage in the current sysplex root file system and reports the active usage in a BPXF245I message. Replacement of the sysplex root file system will continue.
    The migration of the sysplex root file system will begin. During the migration, active connections to files and directories in the current sysplex root file system are broken.

    After the migration completes:

    • The root CWD(‘/’) is updated on all systems in the sysplex to point to the new sysplex root file system.
    • New opens go to the new sysplex root file system. The current sysplex root for the root directory is replaced for all processes in all systems. The current directory for root directory is replaced for any processes using it
    • Old connections in the previous sysplex root file system might get EIO errors.
  4. Update the TYPE parameter and name of the sysplex root file system in the BPXPRMxx member of SYS1.PARMLIB. Because the DDNAME() keyword of the BPXPRMxx ROOT and CMOUNT statements is not supported by zFS, change these statements to use the FILESYSTEM(name) keyword instead.

Reference information

For more information, see the following references:
Parent topic: z/OS UNIX actions to perform before installing z/OS V2R2