Hints for a successful hfs to zfs migration

IBM Systems and Technology Group

SHARE Denver 8/10/2009 © 2003 IBM Corporation

Hints for a Successful HFS to zFS Migration

Ann [email protected] 2255 Wednesday August 26, 2009

2255 Hints for a successful HFS to zFS Migration

© 2003 IBM Corporation2 SHARE Denver 8/10/2009

TrademarksThe following are trademarks of the International Business Machines Corporation in the United States and/or other countries.

The following are trademarks or registered trademarks of other companies.Intel is a trademark of the Intel Corporation in the United States and other countries.Linux is a trademark of Linux Torvalds in the United States, other countries, or both. Java and all Java-related trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.Microsoft, Windows and Windows NT are registered trademarks of Microsoft Corporation.UNIX is a registered trademark of The Open Group in the United States and other countries.* All other products may be trademarks or registered trademarks of their respective companies.

Notes: Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput improvements equivalent to the performance ratios stated here.

IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless, our warranty terms apply.

All customer examples cited or described in this presentation are presented as illustrations of the manner in which some customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics will vary depending on individual customer configurations and conditions.

This publication was produced in the United States. IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for information on the product or services available in your area.

All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.

Information about non-IBM products is obtained from the manufacturers of those products or their published announcements. IBM has not tested those products and cannot confirm the performance, compatibility, or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

Prices subject to change without notice. Contact your IBM representative or Business Partner for the most current pricing in your geography.

This presentation and the claims outlined in it were reviewed for compliance with US law. Adaptations of these claims for use in other geographies must be reviewed by the local country counsel for compliance with local laws.

* Registered trademarks of IBM Corporation

DFSMSdfpDFSMSdssDFSMShsmDFSMSrmm

IBM*IBM eServerIBM e(logo)server*IBM logo*

Language Environment*On demand business logoOS/390*Parallel Sysplex*RACF*RMFS/360S/370S/390

SystemPac*System z9VTAM*z/Architecturez/OS*zSeries*



Topics

Setting up zFS

Defining your first zFS

Migrating your Filesystems

Dynamic Replacement of Sysplex Root

Automount Migration Aids

Backing up the filesystems



zFS Statement of Direction

z/OS V1.7 is planned to be the last release to allow mounting zSeries File System (zFS) file systems contained in multi-file system aggregates that are to be shared across systems in a sysplex. IBM already recommends that these multi-file system aggregates not be shared in a sysplex environment. Once this support has been removed in the release after z/OS 1.7, attempts to mount zfS file systems contained in multi-file system aggregates will fail in a UNIX System Services shared file system environment. Mounting zFS compatibility mode aggregates, which have a single read-write file system per data set, will continue to be supported inall environments.

In a future release, support for zSeries File Systems (zFS) multi-file system aggregates will be withdrawn. When this support is withdrawn, only zFS compatibility mode aggregates will be supported. (A zFS compatibility mode aggregate has a single read-write file system per data set.)

Multi-filesystem aggregates



Setting up zFS



3 ways to grant Authority to do Filesystem Administration1. Assign all administrators UID(0)

altuser chaight omvs(uid(0))

2. Provide READ access to the BPX.SUPERUSER Facility ProfileRDEFINE FACILITY BPX.SUPERUSER UACC(NONE)

PERMIT BPX.SUPERUSER CLASS(FACILITY) ID(CHAIGH1) ACCESS(READ)SETROPTS RACLIST(FACILITY) REFRESH

3. Provide access to the UNIXPRIV profiles SUPERUSER.FILESYS.PFSCTL AND SUPERUSER.FILESYS.MOUNTSETROPTS CLASSACT(UNIXPRIV)SETROPTS RACLIST(UNIXPRIV)RDEFINE UNIXPRIV SUPERUSER.FILESYS.PFSCTL UACC(NONE)PERMIT SUPERUSER.FILESYS.PFSCTL CLASS(UNIXPRIV) ID(CHAIGH2)

ACCESS(READ)RDEFINE UNIXPRIV SUPERUSER.FILESYS.MOUNT UACC(NONE)PERMIT SUPERUSER.FILESYS.MOUNT CLASS(UNIXPRIV) ID(CHAIGH2)

ACCESS(UPDATE)SETROPTS RACLIST(UNIXPRIV) REFRESH



Defining zFS in the BPXPRMxx memberCreate a new BPXPRMxx member with the following FILESYSTYPE statement in it./* FILESYSTYPE DEFINITION FOR DEFINING ZFS */

/* USING SETOMVS RESET=(ZF) */

FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM)

ASNAME(ZFS,'SUB=MSTR') PARM('PRM=(ST,&SYSNUMB)')

The ASNAME statement indicates the name of the procedure to start and that it should not run under JES control.The PARM statement allows us to specify the IOEFSPRM member as a true PARMLIB member.



//ZFS PROC REGSIZE=0M

//*

//ZFZGO EXEC PGM=BPXVCLNY,REGION=&REGSIZE,TIME=1440

//*

//*STEPLIB DD DISP=SHR,DSN=hlq.SIOELMOD <--ZFS LOADLIB

//*IOEZPRM DD DISP=SHR,DSN=SYS4.PVT.PARMLIB(IOEFSPRM) <--ZFS PARM FILE

//*

Creating the zFS PROC

Copy the sample proc from IOE.SIOEPROC in to your PROCLIB.

You do not need to use the STEPLIB since you previously put the LOADLIB in LINKLIST.



Creating the zFS PROC

Use a system qualifier symbolic in the dataset name for the IOEZPRM DD statement so you can use the same proc to start zFS on every system while maintaining system unique parameters.

//ZFS PROC REGSIZE=0M

//ZFSGO EXEC PGM=BPXVCLNY,REGION=&REGSIZE,TIME=1440

//* can step lib below to pickup zfs/smb/dfs from somewhere else

//*STEPLIB DD DISP=SHR,DSN=D10.OE.SIOELMOD,UNIT=3390,VOL=SER=D83OE4

//IOEZPRM DD DISP=SHR,DSN=USER.PLX2.PARMLIB(IOEFSP&SYSNUMB)

//* END



IOEFSPRM. What is it? Where is it? Why should you set it up?

The IOEPRMxx is a list of processing options that allow you to tune and configure zFS.

You can copy the IOEFSPRM from IOE.SIOESAMP in to your parmlib concatenation or to the location you specified in your zFS proc.

Using the PARM parameter of the FILESYSTYPE statement is the preferred format.

You should set this up to:1. Establish a location for zFS tuning parameters across IPLs.



IOEFSPRM options• Sample IOEFSPRM file contents:

adm_threads=7aggrfull(90,2)aggrgrow=onlog_cache_size=10Mmeta_cache_size=80Msync_interval=45user_cache_size=1000Mvnode_cache_size=10000debug_settings_dsn=USER.PLX2.PARMLIB(IOEDEBUG)trace_dsn=OMVS.PRV.TRACEOUT.S1trace_table_size=32M

• F ZFS,QUERY,SETTINGS



IOEFSPRM options 2

• adm_threads - How many zFS tasks to use to perform admin commands

• aggrfull – Controls when zFS reports that an aggregate is low on space.

• aggrgrow – Indicates if dynamic grow on

• log_cache_size – Size of log file cache

• meta_cache_size – Size of metadata cache

• sync_interval – Number of seconds between syncs



IOEFSPRM options 3• user_cache_size – size of the cache used to store

the contents of user files.

• vnode_cache_size – number of files that can be cached in zFS.

• debug_settings_dsn – name of dataset that contains debug settings to debug errors

• trace_dsn – name of dataset that zFS should write the in-memory trace contents to.

• trace_table_size – size of in-core trace table



Start zFS for the First time

From the console, issue one of the following command:

SETOMVS RESET=(XX) or SET OMVS=(xx)Note: xx equals the name of the BPXPRMxx that was set up previously

This will read the BPXPRMxx member and start the zFS address space.

By adding this statement to your existing BPXPRMxx member, zFS will start the next time OMVS is restarted or the next time you IPL.



Defining your first zFS Filesystem



Creating a Compatibility Mode Aggregate

There are two steps to create an aggregate– Allocate a VSAM Linear Dataset– Format the Dataset as a compatibility mode aggregate

and create a filesystem in the aggregate

3 ways to achieve the above steps– Use JCL to allocate the dataset with IDCAMS then use

the IOEAGFMT to format the filesystem.– Use zfsadm define and zfsadm format – Use ISHELL



Mounting your new zFS filesystem

4 Ways to mount the filesystem– Add the mount statements to BPXPRMxx

– Use the ISHELL mount command.

– Use the /usr/sbin/mount command in the shell.

– TSO Mount command• MOUNT Filesystem(‘USSZFS.SHARE.ZFS’) TYPE(ZFS) MODE (RDWR) MOUNTPOINT(‘/SHARE’)



ROOT and MOUNT statements in BPXPRMxx

zFS can now be used as the root filesystem.– ROOT FILESYSTEM('OMVSSPA.SVT.SYSPLEX.ZFS') TYPE(ZFS) MODE(RDWR) MKDIR(‘share')

– MOUNT FILESYSTEM(‘USSZFS.SHARE.ZFS') TYPE(ZFS) MODE(RDWR) MOUNTPOINT('/share')

Availablein z/OS 1.7



Mounting the filesystem using ISHELL



Ready To Migrate



A Couple of Considerations before Migrating

1. Need to have DASD space available to accommodate both the old and new filesystem during the migration

2. Need to make the source filesystem unavailable for updates during the migration.



Basic HFS to zFS Migration Steps

Define a new zFS aggregate

Create temporary directories (Mount points)

Mount both the HFS and zFS filesystems

Use pax to copy the HFS contents to the zFS

Unmount the filesystems

Remove the temporary mount points

Rename the filesystems as appropriate



Tools to migrate HFS data to zFS

Enhancements to pax– Modified to keep sparse files sparse when they are

copied

– Report errors reading a source file and then continue to the next file to be copied

HFS will now be considered a generic file system type that can mean either HFS or ZFS.

A new migration tool will be provided in the form of an ISPF dialog.

Availablein z/OS 1.7



My Example

4 filesystems– USSZFS.SHARE.F1.HFS– USSZFS.SHARE.F2.HFS– USSZFS.SHARE.F3.HFS– USSZFS.SHARE.FS.HFS

USSZFS.SHARE.F1.HFS is mounted on /share and is a 14G Multi-Volume file system spanning 2 mod 9sUSSZFS.SHARE.F2.HFS is mounted on /share/erahsUSSZFS.SHARE.F3.HFS is not mountedUSSZFS.SHARE.FS.HFS is mounted on /share/nomig and we will not be migrating it.



Start the tool by issuing BPXWH2Z –cv from TSO



Migrating the Sysplex Root



Migrating the Sysplex RootDynamic Replacement of Sysplex Root– The replacement is initiated with an operator command on

any system in the shared file system configuration– The sysplex root file system is dynamically replaced while it

is in use without disruption to active workloads

Benefit– Migration of sysplex root file system to zFS file system– Replacement of sysplex root file system PFS to the same or

different PFS (HFS or zFS)

Value– Dynamic migration without a sysplex-wide IPL– Transparent to applications and users on any systems in

sysplex



Migrating the Sysplex Root Cont.Restrictions– All systems in the sysplex must be at the V1R10 level. – The current sysplex root file system PFS, and the new sysplex

root file system PFS, must be up on all the systems in the shared file system configuration.

– 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 rootfile 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 iszFS, then it must be HFS-compatible.



Migrating the Sysplex Root Cont.Constraints Contd…– The sysplex root or any directories on it cannot have been

exported by the DFS™ or SMB server.– 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.



Migrating the Sysplex Root Cont.Migration Steps:

1. Ensure Current sysplex Root is mounted Read Only with No Function Shipping Clients.

a. D OMVS,F,NAME=your.sysplex.root.name2. Allocate and set up the new zFS sysplex root file system

a. Create a new zFS file system to be used as the new sysplex root file system.

i. 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.

b. Set up the active mount points and the symbolic links a. 2 ways Manually or using the pax command

I. Mount new filesystem on temp mount pointII. cd / III. pax -wr -pe -XCM ./ /newrootIV. Unmount new file system



Migrating the Sysplex Root Cont.

3. On any system in the shared file system configuration, issue: F OMVS,NEWROOT=new.root.file.system.name,COND=<Yes|No>

– The following values are accepted:• COND=Yes - Proceed conditionally

– If the sysplex root contains any objects more than mount points and symlinks that are in use, report the activities using BPXF245I message and abort the processing. (Default)

• COND=No - Proceed unconditionally– A disruptive operation. Report the activities using BPXF245I

message, and continue processing.

4. Update the TYPE parameter and name of the sysplex root file system in the BPXPRMxx member of SYS1.PARMLIB.



Migrating Automount File Systems



HFS to zFS migration aids related to automount

• Support available Since z/OS Release 5:• Automount was changed to set the file system type to either HFS or ZFS when either of

those is specified based on the type of data set that is being mounted.

• Support added in z/OS Release 7:• Capability to specify the file system name with substitution place holders

was added. The place holder is /// and represents the string HFS or ZFS as appropriate. Where ///is used, mount processing will first substitute ZFS and check to see if the dataset exists and is not an HFS dataset. If this is the case it will proceed with the name and direct the mount to ZFS. Otherwise mount processing will substitute HFS.

• Note: To be able to use a single automount policy to manage both HFS and zFS file systems, the zFS file system must be a compatibility mode zFS. zFS multi-file system aggregates will not work with this function.



Automount generic entry example

The following is an example of a generic entry: ------ /etc/auto.master ------

/u /etc/u.map

------ /etc/u.map ---------

name *

type ZFS

filesystem OMVS.///.USER.<uc_name>

mode rdwr

duration 30

delay 10

parm FSFULL(50,5)



Backing up your Filesystems



Backup and Recovery

All file systems (HFS and zFS) can be backed up using ADRDSSU

– DFDSS backup of zFS is on an aggregate basis

Customers should not be using full volume dumps to backup file systems.

– Full volume dumps do not quiesce file systems. This dump process will run asynchronous to file system write activity.

Rather, customers should use logical data set level dumps to ensure file system integrity

– For HFS - can be dumped from any system in sysplex

– For zFS – must be dumped from owning system. Solved in Release 7.



Publications Referencesz/OS Distributed File Service zSeries File System Administration (SC24-5989)zFS Concepts and zfsadm command

z/OS Distributed File Services Messages and Codes (SC24-5917)IOEZxxxt messages and X’EFxxrrrr’ reason codes for zFS

z/OS UNIX System Services Planning (GA22-7800)General Administration of z/OS UNIX file systems

z/OS UNIX Command Reference (SA22-7802)confighfs command for HFS

z/OS MVS System Messages Volume 9 (IGF-IWM)IGWxxxt messages for HFS

z/OS UNIX System Services Messages and Codes (SA22-7807)X’5Bxxrrrr’ reason codes for HFS

z/OS Distributed File Service zSeries File System z/OS V1R7 Implementation (SG24-6580)

– Redbook available at– http://www.redbooks.ibm.com/redbooks/SG246580.html– http://www.redbooks.ibm.com/redbooks/pdfs/sg246580.pdf

z/OS V1R10.0 Migration (GA22-7499-13)



Back up Material



HFS-compat Aggregate

my.hfs.compat

• Every aggregate contains a log file (size specified at format time)

• Has exactly one r/w file system

• Optionally can have a clone of r/w file system

• File system name matches dataset name

• Initial quota is size of Aggregate – (size of log file plus some control structures)

• Specify at format time

Log file

my.hfs.compat

my.hfs.compat.bak



zFS Cloninga clone operation makes a point-in-time read/only backup of a zFS file system in the same aggregate– zfsadm clone OMVS.PRV.FS1– IOEZ00225I File system OMVS.PRV.FS1 successfully cloned.only metadata is copied, not user databackup file system has the name of the read/write file system with ".bak" appendedlater, when the read/write file system is modified, a new page is allocated to maintain the backupDeleting file systems (such as backups) – zfsadm delete OMVS.USER.PAT.bak

/

abc def

metadata metadata



zFS Logging and Fast Mount Conversion (R7)zFS is a logging file system

After system failure, next mount replays log to bring file system into consistent state

IOEZ00397I recovery statistics for OMVSSP.SHARE.ZFS:IOEZ00391I Elapsed time was 1505 msIOEZ00392I 135 log pages recovered consisting of 11091 recordsIOEZ00393I Modified 119 data blocksIOEZ00394I 9980 redo-data records, 2 redo-fill recordsIOEZ00395I 13 undo-data records, 0 undo-fill recordsIOEZ00396I 0 not written blocksIOEZ00400I 0 blocks zeroed

R/O mount can fail if log needs to be replayed, but can be avoidedMust be mounted R/W, unmounted and then mounted R/OAdd romount_recovery=on to your IOEFSPRM

Conversion to fast-mount format (z/OS 7)IOEZ00500I Converting MY.COMPAT for fast mount processingIOEZ00518I Converting filesystem MY.COMPAT for fast mount



zFS Kernel Address Space

USS

User cache

Log cache

vnode

metadata

zFS

zFS kernel runs as colony address space

zFS creates multiple dataspaces to contain contents of user files

Log file buffers stored in a dataspace

Main zFS address space contains all other structures and metadata cache



Modify Commands (Performance Stats)• Query commands – show zFS performanceF ZFS,QUERY,ALLF ZFS,RESET,ALL

• zfsadm command can be used for granularityzfsadm query –system J40 –metadata

Metadata Caching StatisticsBuffers (K bytes) Requests Hits Ratio Updates------------ ------------ -------------- ----------- -------- ------------

4096 32768 376849 342429 90.8% 87698• RMF shows zFS kernel performance (z/OS 7)

Hints for a successful hfs to zfs migration

Technology

Transcript of Hints for a successful hfs to zfs migration