zFS Version 1.5 Aggregate and Extended
(v5) Directory
Beginning in z/OS V2R1, zFS supports a new version aggregate, the version 1.5
aggregate. Version 1.5 aggregates support extended (v5) directories. Extended (v5)
directories provide the following benefits:
•
•
•
They can support larger directories with performance.
They store names more efficiently than v4 directories.
When names are removed from extended (v5) directories, the space is reclaimed,
when possible, unlike v4 directories where space is not reclaimed until the
directory is removed.
Version 1.5 aggregates have a larger architected maximum size than version 1.4
aggregates (approximately 16 TB versus approximately 4 TB). Extended (v5) directories
can support more subdirectories than v4 directories (4G-1 versus 64K-1). Because
version 1.5 aggregates will benefit all z/OS V2R1 or later environments, you are
encouraged to use this function only after all of your systems have been migrated to z/OS
V2R1 or a later z/OS version. Version 1.5 aggregates can contain both extended (v5)
directories and v4 directories and either can be a subdirectory of the other. zFS version
1.4 aggregates cannot contain extended (v5) directories. Version 1.5 aggregates can be
mounted on directories contained in version 1.4 aggregates, and the reverse is also
allowed.
Only zFS version 1.5 aggregates can have extended (v5) directories. An existing zFS
version 1.4 aggregate can be converted on z/OS V2R1 to a version 1.5 zFS aggregate,
which allows it to contain both v4 (if existed before the conversion) and extended (v5)
directories. Any new directories created will be an extended (v5) directory. Individual
directories in a zFS version 1.4 aggregate can be converted from v4 to extended (v5)
directories. This will cause an automatic conversion of the aggregate from version 1.4 to
version 1.5, if not at the version 1.5 format, and can only be performed on z/OS V2R1 or
later releases. New directories created in the version 1.5 aggregate will be extended (v5)
directories.
Here are some ways existing v4 directories can be converted to extended (v5) directories:
•
•
•
Explicitly, one at a time, for a mounted aggregate using the zfsadm convert path command, or
Automatically, as they are accessed, for a mounted aggregate when the aggregate
has the converttov5 attribute, or
Offline, converting all directories using the IOEFSUTL converttov5 batch
utility.
Existing directories in a version 1.5 aggregate are not automatically converted if the
NOCONVERTTOV5 MOUNT PARM is specified. Explicit and offline directory
conversion will change the aggregate from version 1.4 to version 1.5, if necessary.
Note: Converting a directory from version v4 to an extended (v5) directory requires both
versions of the directory to exist on disk at the same time, temporarily. If the aggregate
becomes full during the allocation of the new directory a dynamic grow will be
attempted.
Some suggested guidelines for v4 to v5 conversions are:
•
Extended (v5) directories have better performance than v4 directories of the same
size. For optimal performance after all systems at your site have been migrated to
z/OS V2R1, all of the directories should be converted from v4 to v5 even though
support will continue to be provided for v4 directories. To convert selected file
systems or directories, you can use automatic methods (such as specifying the
MOUNT parameters or by using the offline conversion utility). You can also
convert them explicitly with the zfsadm convert command.
•
If your installation exports zFS file systems to NFS or SMB, it is recommended
that the zfsadm convert command not be used for conversions for directories that
are exported by these servers. In rare cases, remote applications can get
unexpected errors if a directory being manually converted is simultaneously being
accessed by NFS or SMB users. Use one of the other methods for the conversion,
such as offline conversion or the CONVERTTOV5 MOUNT parameter, for
these file systems. These methods will ensure that each individual directory is
completely converted before it can be exported.
•
If you are not planning to convert all file systems to v5, then it is best to at least
do the most active file systems or the file systems with large directories. A
directory will get a nontrivial benefit by conversion to v5 if it has 10000 entries or
more (a length of approximately 800 K or more). You can determine the most
active file systems by issuing MODIFY ZFS,QUERY,FILESETS or by using
the wjsfsmon tool. The number of entries in a directory or its size can be
determined by issuing the commands df –t, ls –ld, ls –l, find, or the largedir
utility. The approximate rate of conversion for the directories is between 3500
(for a z9® machine) and 10000 (for a zEC12 machine) directory entries per
second, depending on your processor.
•
After you decide that a file system (aggregate) is going to be converted to version
1.5, you need to decide what conversion method to use. If the file system can be
unmounted, the IOEFSUTL converttov5 batch utility or MOUNT parameters can
be used. If it cannot be unmounted and it is not exported by NFS or SMB servers,
use the zfsadm convert command. If it is exported by NFS or SMB servers, add
the converttov5 attribute to the mounted aggregate.
Care should be taken to make an informed decision before implementing a zFS version
1.5 aggregate in your environment. The main purpose of the version 1.5 aggregate is to
support a new directory format (extended (v5) directory) that will scale better when the
directory contains many objects. Since the format of a new directory is different in a
version 1.5 aggregate, zFS provides toleration APAR OA39466 to be installed on earlier
than z/OS V2R1 supported releases. This will cause a mount of a version 1.5 aggregate
on an earlier than z/OS V2R1 release to fail and resort to z/OS UNIX function shipping.
Earlier than z/OS V2R1 releases cannot locally access an extended (v5) directory or
version 1.5 aggregate. Consider not converting your root file system in the sysplex until
your entire environment is at z/OS V2R1 or later.
In z/OS V2R1 zFS has a new zfsadm command called fileinfo (zfsadm fileinfo). It can
be used to display information about a file or directory. Fileinfo can be used to determine
if the directories in a file system are extended (v5) directories or version v4 directories.
Also note that the default for the zFS IOEPRMxx option CONVERT_AUDITFID is
being changed from OFF to ON. This means that any existing zFS aggregates that have
the non-unique auditfid will be converted to have a unique auditfid on the next read-write
mount.
The following was performed in our parallel sysplex z/OS V2R1 environment.
Determining Directory Candidates for Conversion
If you have long response times, you may have a first indication that you might have a
directory size problem. An examination of the output of the MODIFY ZFS,QUERY,KN
operator command or the z/OS UNIX zfsadm query –knpfs command can be performed.
Look at the Avg Time field on the lines for operations that require zFS to search through
names of a directory (for example, zfs_lookup, zfs_create, or zfs_remove). Typically, the
average times should be on the order of a few milliseconds. If they are relatively large
(perhaps ten to a hundred times larger than that), it is possible that you have a directory
that is too large and is causing performance problems.
Extended (v5) directories will scale better when there are many objects in the directory.
Below are some ways we determined the directory size. These are only examples and
may take some time to complete. You should determine the best approach to take in your
environment.
We have a large version 1.4 aggregate mounted as RWSHARE in our environment.
Using the zfsadm aggrinfo and df commands we see that the file system is large.
$ zfsadm aggrinfo -aggregate OMVSSPN.VER15.ZFS -long
OMVSSPN.VER15.ZFS (R/W COMP): 26600551 K free out of total 59261760
version 1.4
auditfid E2E2F0F0 F0F6AB7C 0020
sysplex-aware
3325068 free 8k blocks;
32800 K log file;
8192 K bitmap file
7 free 1K fragments
80 K filesystem table
$ df -vkP /zfspetmounts/zfsver15A/
Filesystem
1024-blocks
Used
on
OMVSSPN.VER15.ZFS
59261760
32661209
/zfspetmounts/zfsver15A
ZFS, Read/Write, Device:7776, ACLS=Y
File System Owner : TPN
Automove=Y
Filetag : T=off
codeset=0
Aggregate Name : OMVSSPN.VER15.ZFS
Available
Capacity Mounted
26600551
56%
Client=N
Using the ‘df –t’ command, we see that there are many allocated file slots in this file
system.
$ df -t
/zfspetmounts/zfsver15A
Mounted on
Filesystem
Avail/Total
Files
Status
/zfspetmounts/zfsver15A (OMVSSPN.VER15.ZFS)
53201102/118523520
4291102111/4294967295 Available
One way to see if there are large directories in the file system that may be candidates for
conversion to extended (v5) directories is to use the largedir utility. You can use the
largedir.pl utility, which currently requires perl, to help determine which zFS directories
are large (1MB or greater and 3MB or greater). The largedir.pl utility is available on the
z/OS UNIX System Services Tools and Toys Web page as zFS Large Directory Utility
(http://www.ibm.com/systems/z/os/zos/features/unix/bpxa1ty2.html).
You can also issue a ‘find’ command to search for file system directories that are greater
than 1MB.
An example would be:
$ find /zfspetmounts/zfsver15A -type d -xdev -size +1048575c
We issued the largedir utility (located in our environment at /local/largedir/largedir)
against the mountpoint that the file system was mounted on. It resulted in the following.
The Minor Exceptions are over 1MB and the Major Exceptions are over 3MB.
$ /local/largedir/largedir /zfspetmounts/zfsver15A
Minor Exception: Large Directory: /zfspetmounts/zfsver15A/JA0/D3
Minor Exception: Large Directory: /zfspetmounts/zfsver15A/JE0/D3
Minor Exception: Large Directory: /zfspetmounts/zfsver15A/JJ0/D2
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JJ0/D3
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JH0/D0
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JH0/D1
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JD0/D0
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JD0/D1
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JD0/D2
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JD0/D3
Major Exception: Really Large Directory: /zfspetmounts/zfsver15A/JG0/D2
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Major
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Exception:
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Really
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Large
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
Directory:
/zfspetmounts/zfsver15A/JG0/D3
/zfspetmounts/zfsver15A/JF0/D0
/zfspetmounts/zfsver15A/J80/D3
/zfspetmounts/zfsver15A/Z0/D0
/zfspetmounts/zfsver15A/Z0/D1
/zfspetmounts/zfsver15A/Z0/D2
/zfspetmounts/zfsver15A/Z0/D3
/zfspetmounts/zfsver15A/J90/D1
/zfspetmounts/zfsver15A/J90/D2
/zfspetmounts/zfsver15A/J90/D3
/zfspetmounts/zfsver15A/JL0/D0
/zfspetmounts/zfsver15A/JL0/D1
/zfspetmounts/zfsver15A/JL0/D2
/zfspetmounts/zfsver15A/JL0/D3
/zfspetmounts/zfsver15A/JB0/D1
/zfspetmounts/zfsver15A/JB0/D2
/zfspetmounts/zfsver15A/JB0/D3
Using the ls –ld command, we see that the directories are greater than 1MB and contain
many names (or at one time contained many names).
Here are some examples:
$ ls -ld /zfspetmounts/zfsver15A/JA0/D3
drwx-----2 ALEASE1 sys1
1187840 Sep 25 23:35
/zfspetmounts/zfsver15A/JA0/D3
$ ls -ld /zfspetmounts/zfsver15A/JJ0/D3
drwx-----2 ALEASE1 sys1
4898816 Sep 25 22:26
/zfspetmounts/zfsver15A/JJ0/D3
Using the ls –l and word count (wc) commands, we can see that there are currently
many files in the directory and the approximate byte count.
Here are some examples (we filtered out the Total statement from the ls command output
to get an accurate count, knowing that we did not have files with names that contain otal):
$ ls -l /zfspetmounts/zfsver15A/JA0/D3 | grep -v 'otal' | wc -lc
36235 2174100
$ ls -l /zfspetmounts/zfsver15A/JJ0/D3 | grep -v 'otal' | wc -lc
150000 9000000
Convert a Mounted zFS Version 1.4 Aggregate to a zFS
Version 1.5 Aggregate Using the –converttov5 Configuration
Option
We determined that the OMVSSPN.VER15.ZFS file system was a candidate for
extended (v5) directories.
Using the method of having the zFS configuration –converttov5 option ON to update the
attributes of a mounted file system, we gave the file system the converttov5 parameter.
We ensured that no other file systems were mounted or moved to this system while we
were performing this activity.
On the USS-owning system, display the –converttov5 configuration option. Then set it
to on.
$ zfsadm configquery -converttov5
IOEZ00317I The value for configuration option -converttov5 is OFF.
$ zfsadm config -converttov5 on
IOEZ00300I Successfully set -converttov5 to on
$ zfsadm configquery -converttov5
IOEZ00317I The value for configuration option -converttov5 is ON.
Next, on the USS-owning system remount samemode the file system.
UNMOUNT FILESYSTEM('OMVSSPN.VER15.ZFS') REMOUNT(SAMEMODE)
Here are sample zFS messages you may see.
IOEZ00048I Detaching aggregate OMVSSPN.VER15.ZFS
IOEZ00044I Aggregate OMVSSPN.VER15.ZFS attached successfully.
The file system now has the converttov5 attribute and was converted to a version 1.5
aggregate. As the directories are accessed, they will be converted to extended (v5)
directories. New directories will be extended (v5) directories. You can see the attribute
assigned via the zfsadm aggrinfo command.
$ zfsadm aggrinfo -aggregate OMVSSPN.VER15.ZFS -long
OMVSSPN.VER15.ZFS (R/W COMP): 26600551 K free out of total 59261760
version 1.5
auditfid E2E2F0F0 F0F6AB7C 0020
sysplex-aware, converttov5
3325068 free 8k blocks;
7 free 1K fragments
32800 K log file;
80 K filesystem table
8192 K bitmap file
Since, we did not want to have other mounted, remounted, or moved file systems to have
this parameter, we turned –converttov5 off on this system.
$ zfsadm config -converttov5 off
IOEZ00300I Successfully set -converttov5 to off
$ zfsadm configquery -converttov5
IOEZ00317I The value for configuration option -converttov5 is OFF.
Create a zFS Version 1.5 Aggregate
A version 1.5 aggregate can be created on z/OS V2R1 by formatting a VSAM LDS as
version 5 using the zFS IOEFSUTL format batch utility or the z/OS UNIX zfsadm
format command. Version 1.5 aggregates are not formatted by default. They must be
explicitly requested with the -version5 option. You can change the default version that is
formatted by setting the format_aggrversion configuration option to 5.
Note: When the -version4 or -version5 parameters are not provided, the zFS format
utilities IOEAGFMT and IOEFSUTL request the value of the format_aggrversion
configuration option from the zFS kernel to determine the default aggregate version for
the format. If the zFS PFS is down they will fail.
This configuration option (format_aggrversion) also affects both of the following:
•
•
The zfsadm format command when neither the -version4 nor the -version5 option
is specified, and
Users of the Format Aggregate API such as the BPXWH2Z tool, the z/OS UNIX
TSO/E ISHELL command, or the z/OS UNIX automount shell command with the
allocany or allocuser keyword.
Note: The IOEFSUTL batch program only formats with new auditfids. This means that
new zFS aggregates will have a unique auditfid by default.
Note: The default for the zFS IOEPRMxx option, CONVERT_AUDITFID, is being
changed from OFF to ON. This means that any existing zFS aggregates that have the
non-unique auditfid will be converted to have a unique auditfid on the next read-write
mount.
Note: The IOEAGFMT batch program and the zfsadm format command have changed
the default to -newauditfid.
The zfsadm aggrinfo command with the –long option can be used to display the
aggregate version.
Below are the results of creating a zFS version 1.5 aggregate in our environment using
the following techniques after all systems were migrated to z/OS V2R1:
•
•
•
zFS IOEFSUTL format batch utility.
The z/OS UNIX zfsadm format command.
Change the default version that is formatted by setting the format_aggrversion
configuration option to 5.
Create a zFS Version 1.5 Aggregate Using IOEFSUTL
To create a zFS Version 1.5 aggregate using the zFS IOEFSUTL format batch utility, we
first defined the VSAM LDS using these attributes:
DEFINE CLUSTER (NAME(OMVSSPT.V15.ZFS) LINEAR CYL(1000 100) SHAREOPTIONS(3) STORCLAS(SMSOE) DATACLAS(SMSOE) -
MGMTCLAS(SMSOE))
We then formatted the aggregate as a version 1.5 with the following JCL definitions:
...
//CREATE EXEC PGM=IOEFSUTL,REGION=0M,
// PARM=('format -aggregate OMVSSPT.V15.ZFS -version5')
...
This is an example of the format results:
IOEZ00559I zFS IOEFSUTL: Initializing z/OS
zFS
Version 02.01.00 Service Level OA41870 - HZFS410.
Created on Mon Jun 3 12:34:28 EDT 2013.
Address space asid x46
IOEZ00760I No IOEZPRM DD specified. Parmlib search being used.
IOEZ00004I Formatting to 8K block number 90000 for primary extent of
OMVSSPT.V15.ZFS.
IOEZ00005I Primary extent loaded successfully for OMVSSPT.V15.ZFS.
IOEZ00077I HFS-compatibility aggregate OMVSSPT.V15.ZFS has been
successfully created.
We then TSO mounted the zFS Version 1.5 (/zfspetmounts/zfsv15) off of a zFS Version
1.4 mounted file system (/zfspetmounts). Note that you can not mount a version 1.5
aggregate on a prior to z/OS V2R1 system. You will receive reason codes like
EF096A32, which describe the condition where a new version aggregate cannot be
processed on this system.
MOUNT FILESYSTEM('OMVSSPT.V15.ZFS') TYPE(ZFS)
MODE(RDWR) MOUNTPOINT('/zfspetmounts/zfsv15')
Next we used the new z/OS V2R1 zFS zfsadm fileinfo command to display the directory
versions.
The version 1.4 file system mountpoint directory showed as a v4 directory.
$ zfsadm fileinfo -path /zfspetmounts
path: /zfspetmounts
***
global data
***
fid
3196,8947036
1983,7320
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
dir name count
na
dir tree status
na
file format bits
na,na,na
file cver
na
anode
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
BLOCKED
777
0,0
0,0
N,N,N
none
8
4
6
na
na
na
direct blocks
0x00003A25
indirect blocks
none
mtime
Jun 25 13:38:19 2013
ctime
Jun 25 13:38:19 2013
reftime
none
atime
create time
Jun 25 13:39:25 2013
May 21 13:35:10 2009
The version 1.5 file system mountpoint directory showed as an extended (v5) directory.
$ zfsadm fileinfo -path /zfspetmounts/zfsv15
path: /zfspetmounts/zfsv15
***
global data
***
fid
1,1
anode
49228,516
length
8192
format
BLOCKED
1K blocks
8
permissions
755
uid,gid
0,0
access acl
0,0
dir model acl
0,0
file model acl
0,0
user audit
F,F,F
auditor audit
N,N,N
set sticky,uid,gid
0,0,0
seclabel
none
object type
DIR
object linkcount
2
object genvalue
0x00000000
dir version
5
dir name count
2
dir data version
0
dir tree status
VALID
dir conversion
na
file format bits
na,na,na
file charset id
na
file cver
na
charspec major,minor
na
direct blocks
0x0000B602
indirect blocks
none
mtime
Jun 25 12:58:58 2013
atime
Jun 25 12:58:58 2013
ctime
Jun 25 12:58:58 2013
create time Jun 25 12:58:58 2013
reftime
none
Create a zFS Version 1.5 Aggregate Using zfsadm format
The following are the steps we took to create a version 1.5 aggregate using the z/OS
UNIX zfsadm format command.
First, we allocated the aggregate using the zfsadm define command.
$ zfsadm define -aggr OMVSSPT.V15.ZFS -cyl 1000 100
IOEZ00248I VSAM linear dataset OMVSSPT.V15.ZFS successfully created.
Then we formatted the aggregate using the zfsadm format –version5 command.
$ zfsadm format -aggr OMVSSPT.V15.ZFS -version5
IOEZ00077I HFS-compatibility aggregate OMVSSPT.V15.ZFS has been
successfully created
We then mounted the file system from the z/OS V2R1 system. Note that the local mount
will fail on lower than z/OS V2R1 releases.
$ mount -f OMVSSPT.V15.ZFS /zfspetmounts/zfsv15
Using the zfsadm aggrinfo command with the –long parameter, we see that it is a
version 1.5 aggregate.
$ zfsadm aggrinfo -aggr OMVSSPT.V15.ZFS -long
OMVSSPT.V15.ZFS (R/W COMP): 718311 K free out of total 725760
version 1.5
auditfid E2E2F0F0 F2F6E80B 0030
sysplex-aware
89788 free 8k blocks;
7 free 1K fragments
7264 K log file;
48 K filesystem table
112 K bitmap file
If you mounted the file system as sysplex-aware (for example: RWSHARE or read-only)
and there are no lower releases in the sysplex, and you have connectivity, the file system
displays will show as not being a client (CLIENT=N). Also, any mount parameters
provided with the mount will display. Here is a df command display.
$ df -vkP /zfspetmounts/zfsv15
Filesystem
1024-blocks
Used
on
OMVSSPT.V15.ZFS
725760
7449
/zfspetmounts/zfsv15
ZFS, Read/Write, Device:3943, ACLS=Y
File System Owner : Z1
Automove=Y
Filetag : T=off
codeset=0
Aggregate Name : OMVSSPT.V15.ZFS
Available
718311
Capacity Mounted
2%
Client=N
We used the new z/OS V2R1 zfsadm fileinfo command to display the directory versions.
The version 1.4 file system mountpoint directory showed as a v4 directory.
$ zfsadm fileinfo -path /zfspetmounts
path: /zfspetmounts
***
global data
***
fid
3196,8947036 anode
1983,7320
length
8192
format
BLOCKED
1K blocks
8
permissions
777
uid,gid
0,0
access acl
0,0
dir model acl
0,0
file model acl
0,0
user audit
F,F,F
auditor audit
N,N,N
set sticky,uid,gid
0,0,0
seclabel
none
object type
DIR
object linkcount
8
object genvalue
0x00000000
dir version
4
dir name count
na
dir data version
6
dir tree status
na
dir conversion
na
file format bits
na,na,na
file charset id
na
file cver
na
charspec major,minor
na
direct blocks
0x00003A25
indirect blocks
none
mtime
Jun 25 13:38:19 2013
atime
Jun 25 14:22:29 2013
ctime
Jun 25 13:38:19 2013
create time May 21 13:35:10 2009
reftime
none
The version 1.5 file system mountpoint directory showed as an extended (v5) directory.
$ zfsadm fileinfo -path /zfspetmounts/zfsv15
path: /zfspetmounts/zfsv15
***
global data
***
fid
1,1
anode
21496,516
length
8192
format
BLOCKED
1K blocks
8
permissions
755
uid,gid
0,0
access acl
0,0
dir model acl
0,0
file model acl
0,0
user audit
F,F,F
auditor audit
N,N,N
set sticky,uid,gid
0,0,0
seclabel
none
object type
DIR
object linkcount
2
object genvalue
0x00000000
dir version
5
dir name count
2
dir data version
0
dir tree status
VALID
dir conversion
na
file format bits
na,na,na
file charset id
na
file cver
na
charspec major,minor
na
direct blocks
0x000001EA
indirect blocks
none
mtime
Jun 25 14:20:32 2013
atime
Jun 25 14:20:32 2013
ctime
Jun 25 14:20:32 2013
create time Jun 25 14:20:32 2013
reftime
none
Create a zFS Version 1.5 Aggregate Using format_aggrversion
Configuration option
The following are the steps we took to create a Version 1.5 aggregate using the default
version that is formatted by setting the format_aggrversion configuration option to 5.
First, we queried the format_aggrversion setting and saw it is set to the default version 4.
$ zfsadm configquery -format_aggrversion
IOEZ00317I The value for configuration option -format_aggrversion is 4.
We then dynamically changed the format_aggrversion setting to 5.
$ zfsadm config
-format_aggrversion 5
IOEZ00300I Successfully set -format_aggrversion to 5
We queried the format_aggrversion setting after and saw it is now set to the version 5.
$ zfsadm configquery -format_aggrversion
IOEZ00317I The value for configuration option -format_aggrversion is 5.
Then, we defined the aggregate.
$ zfsadm define -aggr OMVSSPT.V15.ZFS -cyl 1000 100
IOEZ00248I VSAM linear dataset OMVSSPT.V15.ZFS successfully created.
We used the zfsadm format command to format the aggregate and it was formatted as a
version 1.5 aggregate.
$ zfsadm format -aggr OMVSSPT.V15.ZFS
IOEZ00077I HFS-compatibility aggregate OMVSSPT.V15.ZFS has been
successfully created
The aggregate was then mounted on /zfspetmounts/zfsv15.
$ mount -f OMVSSPT.V15.ZFS /zfspetmounts/zfsv15
Using the zfsadm fileinfo command we see that the version 1.5 file system
mountpoint directory showed as an extended (v5) directory.
$ zfsadm fileinfo -path /zfspetmounts/zfsv15
path: /zfspetmounts/zfsv15
***
global data
***
fid
1,1
anode
14825,516
length
8192
format
BLOCKED
1K blocks
8
permissions
755
uid,gid
0,0
access acl
0,0
dir model acl
0,0
file model acl
0,0
user audit
F,F,F
auditor audit
N,N,N
set sticky,uid,gid
0,0,0
seclabel
none
object type
DIR
object linkcount
2
object genvalue
0x00000000
dir version
5
dir name count
2
dir data version
0
dir tree status
VALID
dir conversion
na
file format bits
na,na,na
file charset id
na
file cver
na
charspec major,minor
na
direct blocks
0x00012355
indirect blocks
none
mtime
Jun 25 14:43:23 2013
atime
Jun 25 14:43:23 2013
ctime
Jun 25 14:43:23 2013
create time Jun 25 14:43:23 2013
reftime
none
Convert a zFS Version 1.4 Aggregate to a Version 1.5
Aggregate
You can convert a zFS version 1.4 aggregate to a version 1.5 aggregate with the online
zfsadm convert command on z/OS V2R1. The aggregate can contain v4 and extended
(v5) directories. All new directories will be extended (v5) directories. The v4 directories
can be converted later using various convert commands and parameters.
Note: Online conversion of an aggregate to version 1.5 can not take place if the owner is
down-level, there are down-level members in the sysplex, or the aggregate is mounted
read-only.
If the file system can be unmounted, the IOEFSUTL converttov5 batch utility or
MOUNT parameters can be used. If it cannot be unmounted and it is not exported by
NFS or SMB servers, use the zfsadm convert command. If it is exported by NFS or
SMB servers, add the converttov5 attribute to the mounted aggregate.
Convert a zFS Version 1.4 Using zfsadm convert
We took the following steps and converted a mounted version 1.4 aggregate, with
existing v4 directories, to a version 1.5 aggregate without converting the existing
directories to extended (v5) directories, using zfsadm convert. Version 1.5 aggregates
can support both v4 and extended v5 directories. All our systems were at the z/OS V2R1
release level.
Using zfsadm aggrinfo, with the –long option, we see that the aggregate was originally a
zFS version 1.4.
$ zfsadm aggrinfo -aggregate omvsspn.pet3.zfs.fs -long
OMVSSPN.PET3.ZFS.FS (R/W COMP): 1960823 K free out of total 1961280
version 1.4
auditfid E2E2F0F0 F7F909ED 0000
sysplex-aware
245102 free 8k blocks;
7 free 1K fragments
112 K log file;
56 K filesystem table
280 K bitmap file
We converted the aggregate to a version 1.5, with the existing directories remaining as v4
directories, by using the –aggrversion option for the convert command.
$ zfsadm convert -aggrversion omvsspn.pet3.zfs.fs
IOEZ00810I Successfully changed aggregate omvsspn.pet3.zfs.fs to
version 1.5
After the convert the aggregate is now a zFS version 1.5.
$ zfsadm aggrinfo -aggregate omvsspn.pet3.zfs.fs -long
OMVSSPN.PET3.ZFS.FS (R/W COMP): 1960823 K free out of total 1961280
version 1.5
auditfid E2E2F0F0 F7F909ED 0000
sysplex-aware
245102 free 8k blocks;
7 free 1K fragments
112 K log file;
56 K filesystem table
280 K bitmap file
Since we only converted the aggregate to a version 1.5, the directories remain as v4
directories. This was displayed by using the zfsadm fileinfo command.
$ zfsadm fileinfo -path /pet3
path: /pet3
***
global data
***
fid
1,1
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
anode
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
79,516
BLOCKED
777
0,0
0,0
N,N,N
none
3
4
dir name count
na
dir tree status
na
file format bits
na,na,na
file cver
na
direct blocks
0x00000044
indirect blocks
none
mtime
Jul 26 13:22:36 2013
ctime
Jul 26 13:22:36 2013
reftime
none
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
2836
na
na
na
Jul 26 13:18:53 2013
Jul 12 14:34:46 2002
Next, we made a directory, which will be an extended (v5) directory.
$ mkdir /pet3/v15dirAv5
Using the zfsadm fileinfo command we see that the directory created in the zFS version
1.5 aggregate was an extended (v5) directory.
$ zfsadm fileinfo -path /pet3/v15dirAv5
path: /pet3/v15dirAv5
***
global data
***
fid
5,1435
anode
79,1524
length
8192
format
BLOCKED
1K blocks
8
permissions
775
uid,gid
0,0
access acl
0,0
dir model acl
0,0
file model acl
0,0
user audit
F,F,F
auditor audit
N,N,N
set sticky,uid,gid
0,0,0
seclabel
none
object type
DIR
object linkcount
2
object genvalue
0x00000000
dir version
5
dir name count
3
dir data version
1
dir tree status
VALID
dir conversion
na
file format bits
na,na,na
file charset id
na
file cver
na
charspec major,minor
na
direct blocks
0x00003219
indirect blocks
none
mtime
Jul 26 14:07:08 2013
atime
Jul 26 14:06:37 2013
ctime
Jul 26 14:07:08 2013
create time Jul 26 14:06:37 2013
reftime
none
We did the following to test that directories created under a v4 directory in a version 1.5
aggregate will be extended (v5) directories.
$ mkdir /pet3/origdirAv4/aftv15dirAunderv4
$ zfsadm fileinfo -path /pet3/origdirAv4/aftv15dirAunderv4
path: /pet3/origdirAv4/aftv15dirAunderv4
***
global data
***
fid
8,1435
anode
length
8192
format
1K blocks
8
permissions
uid,gid
0,0
access acl
dir model acl
0,0
file model acl
user audit
F,F,F
auditor audit
set sticky,uid,gid
0,0,0
seclabel
object type
DIR
object linkcount
object genvalue
0x00000000
dir version
79,2280
BLOCKED
775
0,0
0,0
N,N,N
none
2
5
dir name count
2
dir tree status
VALID
file format bits
na,na,na
file cver
na
direct blocks
0x00024173
indirect blocks
none
mtime
Jul 26 14:22:14 2013
ctime
Jul 26 14:22:14 2013
reftime
none
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
0
na
na
na
Jul 26 14:22:14 2013
Jul 26 14:22:14 2013
Convert a zFS Version 1.4 Using IOEFSUTL converttov5
We converted an unmounted version 1.4 aggregate to a version 1.5 aggregate without
converting the existing directories to extended v5, using the IOEFSUTL converttov5
and –aggrversion_only parameter. All our systems were at the z/OS V2R1 release level.
File system mounted on /pet3 was a version 1.4 aggregate. The file system was
unmounted.
$ unmount /pet3
We executed the batch IOEFSUTL utility, using the –aggrversion_only parameter, to
only format the aggregate. Here are excerpts from the JCL.
…
//CONVERT EXEC PGM=IOEFSUTL,REGION=0M,
// PARM=('converttov5 -aggregate OMVSSPN.PET3.ZFS.FS -aggrversion_only
X
//
')
…
Here is an example of the results from the execution.
IOEZ00559I zFS IOEFSUTL: Initializing z/OS
zFS
Version 02.01.00 Service Level EA42544 - HZFS410.
Created on Tue Jun 18 14:08:47 EDT 2013.
Address space asid x5B
IOEZ00760I No IOEZPRM DD specified. Parmlib search being used.
IOEZ00812I Successfully changed aggregate OMVSSPN.PET3.ZFS.FS to
version 1.5.
The file system was mounted.
$ mount -f OMVSSPN.PET3.ZFS.FS /pet3
Since we only converted the aggregate to a version 1.5 aggregate (-aggrversion_only),
the directories remained as v4 directories. We used zfsadm fileinfo to display the
version of the directory.
$ zfsadm fileinfo -path /pet3
path: /pet3
***
global data
***
fid
1,1
anode
79,516
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
dir name count
na
dir tree status
na
file format bits
na,na,na
file cver
na
direct blocks
0x00000044
indirect blocks
none
mtime
Aug 22 13:26:35 2011
ctime
Aug 22 13:26:35 2011
reftime
none
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
BLOCKED
777
0,0
0,0
N,N,N
none
4
4
2830
na
na
na
Jul 8 13:17:57 2013
Jul 12 14:34:46 2002
Using zfsadm aggrinfo we see that this is a version 1.5 aggregate.
$ zfsadm aggrinfo -aggregate OMVSSPN.PET3.ZFS.FS -long
OMVSSPN.PET3.ZFS.FS (R/W COMP): 1960820 K free out of total 1961280
version 1.5
auditfid E2E2F0F0 F7F909ED 0000
sysplex-aware
245100 free 8k blocks;
20 free 1K fragments
112 K log file;
56 K filesystem table
280 K bitmap file
We tested to see that directories made after show as extended (v5) directories.
$ mkdir /pet3/v15aggrmkdir
$ zfsadm fileinfo -path /pet3/v15aggrmkdir
path: /pet3/v15aggrmkdir
***
global data
***
fid
5,1433
anode
79,1524
length
8192
format
BLOCKED
1K blocks
8
permissions
775
uid,gid
0,0
access acl
0,0
dir model acl
0,0
file model acl
0,0
user audit
F,F,F
auditor audit
N,N,N
set sticky,uid,gid
0,0,0
seclabel
none
object type
DIR
object linkcount
2
object genvalue
0x00000000
dir version
5
dir name count
2
dir data version
0
dir tree status
VALID
dir conversion
na
file format bits
na,na,na
file charset id
na
file cver
na
charspec major,minor
na
direct blocks
0x00000CAD
indirect blocks
none
mtime
Jul 8 13:27:38 2013
atime
Jul 8 13:27:38 2013
ctime
Jul 8 13:27:38 2013
create time Jul 8 13:27:38 2013
reftime
none
Convert a zFS Version 1.5 Aggregate to a Version 1.4
Aggregate
You can convert a version 1.5 aggregate to a version 1.4 aggregate by using the
IOEFSUTL utility. Since, the aggregate will be a version 1.4 and can not contain
extended (v5) directories, all extended (v5) directories will be converted to v4 directories.
The file system needs to be unmounted and the convert needs to be executed on a z/OS
V2R1 system.
Note: The zFS IOEFSUTL utility with the converttov4 parameter can be used to
convert a version 1.5 aggregate to a version 1.4 aggregate as long as it is no larger than 4
TB and does not have any extended (v5) directories with more than 64K-1 subdirectories.
This includes converting extended (v5) directories into old format (v4) directories.
For example, we had mounted a version 1.5 aggregate
(OMVSSPN.VER14.TO.VER15.ZFS) that was earlier converted from a version 1.4 to a
version 1.5, and all the directories were converted to extended (v5) directories. We then
used the IOEFSUTL utility to convert the aggregate to a version 1.4 aggregate.
Unmount the file system.
$ unmount /zfspetmounts/ver14tover15
Here are JCL excerpts we used to convert a version 1.5 aggregate offline to a version 1.4
aggregate.
…
//CONVERT EXEC PGM=IOEFSUTL,REGION=0M,
// PARM=('converttov4 -aggregate OMVSSPN.VER14.TO.VER15.ZFS')
…
This is an example of the conversion to version 1.4 results.
IOEZ00559I zFS IOEFSUTL: Initializing z/OS
zFS
Version 02.01.00 Service Level OA42544 - HZFS410.
Created on Mon Jul 22 11:34:59 EDT 2013.
Address space asid x3B
IOEZ00760I No IOEZPRM DD specified. Parmlib search being used.
IOEZ00800I Conversion has processed 7 of 7 objects in the anode table.
IOEZ00803I 3 directories were found, 3 converted, 3 directory pages
converted to 3 directory pages.
IOEZ00810I Successfully changed aggregate OMVSSPN.VER14.TO.VER15.ZFS to
version 1.4.
IOEZ00808I Successfully converted all directories in aggregate
OMVSSPN.VER14.TO.VER15.ZFS to version 4.
After mounting without any parameters we see that it is now a version 1.4 aggregate and
the directories are back to v4.
MOUNT FILESYSTEM('OMVSSPN.VER14.TO.VER15.ZFS') TYPE(ZFS)
MODE(RDWR) MOUNTPOINT('/zfspetmounts/ver14tover15')
Using zfsadm fileinfo we see that the aggregate is back to version 1.4.
$ zfsadm aggrinfo -aggregate OMVSSPN.VER14.TO.VER15.ZFS -long
OMVSSPN.VER14.TO.VER15.ZFS (R/W COMP): 1263 K free out of total 1440
version 1.4
auditfid E2E2F0F0 F1F41A4E 0000
sysplex-aware
157 free 8k blocks;
7 free 1K fragments
112 K log file;
16 K filesystem table
8 K bitmap file
Using zfsadm fileinfo, we see that all directories are back to v4.
$ zfsadm fileinfo -path /zfspetmounts/ver14tover15
$ zfsadm fileinfo -path /zfspetmounts/ver14tover15/origv14dir1
$ zfsadm fileinfo -path /zfspetmounts/ver14tover15/origv14dir2
All show within the fileinfo display:
...
object genvalue
…
0x00000000
dir version
4
Convert v4 Directory to Extended (v5) Directory
Once an aggregate is a version 1.5 aggregate, new directories created in it will be
extended (v5) directories. On our all z/OS V2R1 sysplex, we converted directories to
extended (v5) directories by using one or all of the following (Note: only allowed on a
z/OS V2R1 or later system):
•
•
•
Explicitly, one at a time, for a mounted aggregate using the zfsadm convert path command.
Automatically, as they are accessed, for a mounted aggregate when the aggregate
has the converttov5 attribute.
Offline, converting all directories using the IOEFSUTL converttov5 batch utility.
A v4 directory can be converted to an extended (v5) directory by using copy (cp) if the
target is a version 1.5 aggregate. A v4 directory can be converted to an extended (v5)
directory using the move (mv) command if the target is in a different version 1.5
aggregate and the directory is created as a result of the move.
Convert a v4 Directory Using zfsadm convert -path
We converted an existing v4 directory in a version 1.5 aggregate to an extended (v5)
directory using the zfsadm convert –path command.
An aggregate (OMVSSPN.PET3.ZFS.FS mounted on /pet3) was converted earlier to a
version 1.5 aggregate from a version 1.4 aggregate without converting the existing
directories to extended (v5) directories.
We now want to convert the root directory of /pet3 to an extended (v5) directory.
Check that the aggregate is a version 1.5 aggregate with the zfsadm aggrinfo command,
using the –long option.
$ zfsadm aggrinfo -aggregate OMVSSPN.PET3.ZFS.FS -long
OMVSSPN.PET3.ZFS.FS (R/W COMP): 1960807 K free out of total 1961280
version 1.5
auditfid E2E2F0F0 F7F909ED 0000
sysplex-aware
245100 free 8k blocks;
7 free 1K fragments
112 K log file;
56 K filesystem table
280 K bitmap file
We used zfsadm fileinfo to display that the directories are v4 directories.
$ zfsadm fileinfo -path /pet3/
path: /pet3/
***
global data
***
fid
1,1
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
dir name count
na
dir tree status
na
file format bits
na,na,na
file cver
na
direct blocks
0x00000044
indirect blocks
none
mtime
Jul 26 14:07:24 2013
ctime
Jul 26 14:07:24 2013
reftime
none
anode
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
79,516
BLOCKED
777
0,0
0,0
N,N,N
none
4
4
2838
na
na
na
Jul 26 14:19:23 2013
Jul 12 14:34:46 2002
$ zfsadm fileinfo -path /pet3/origdirAv4/
path: /pet3/origdirAv4/
***
global data
***
fid
2,1435
anode
length
8192
format
1K blocks
8
permissions
uid,gid
0,0
access acl
dir model acl
0,0
file model acl
user audit
F,F,F
auditor audit
set sticky,uid,gid
0,0,0
seclabel
object type
DIR
object linkcount
object genvalue
0x00000000
dir version
dir name count
na
dir data version
79,768
BLOCKED
775
0,0
0,0
N,N,N
none
3
4
2
dir tree status
na
file format bits
na,na,na
file cver
na
direct blocks
0x00009A2E
indirect blocks
none
mtime
Jul 26 14:22:14 2013
ctime
Jul 26 14:22:14 2013
reftime
none
dir conversion
file charset id
charspec major,minor
atime
create time
na
na
na
Jul 26 13:19:52 2013
Jul 26 13:19:52 2013
Convert the root directory of the file system to an extended (v5) directory using the
zfsadm convert –path command.
$ zfsadm convert -path /pet3
IOEZ00791I Successfully converted directory /pet3 to version 5 format.
After the root directory, /pet3, was converted to extended (v5) directory, the directory is
now an extended (v5) directory, and the existing v4 directories under it are still at the v4
version.
$ zfsadm fileinfo -path /pet3
path: /pet3
***
global data
***
fid
1,1
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
dir name count
6
dir tree status
VALID
file format bits
na,na,na
file cver
na
direct blocks
0x00005D80
indirect blocks
none
mtime
Jul 26 14:07:24 2013
ctime
Jul 26 14:07:24 2013
reftime
none
anode
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
79,516
BLOCKED
777
0,0
0,0
N,N,N
none
4
5
4
na
na
na
Jul 26 14:50:48 2013
Jul 12 14:34:46 2002
$ zfsadm fileinfo -path /pet3/origdirAv4/
path: /pet3/origdirAv4/
***
global data
***
fid
2,1435
anode
length
8192
format
1K blocks
8
permissions
uid,gid
0,0
access acl
dir model acl
0,0
file model acl
user audit
F,F,F
auditor audit
set sticky,uid,gid
0,0,0
seclabel
object type
DIR
object linkcount
object genvalue
0x00000000
dir version
dir name count
na
dir data version
dir tree status
na
dir conversion
file format bits
na,na,na
file charset id
79,768
BLOCKED
775
0,0
0,0
N,N,N
none
3
4
2
na
na
file cver
na
direct blocks
0x00009A2E
indirect blocks
none
mtime
Jul 26 14:22:14 2013
ctime
Jul 26 14:22:14 2013
reftime
none
charspec major,minor
atime
create time
na
Jul 26 13:19:52 2013
Jul 26 13:19:52 2013
Now lets convert the other v4 directory to an extended (v5) directory.
$ zfsadm convert -path /pet3/origdirAv4/
IOEZ00791I Successfully converted directory /pet3/origdirAv4/ to
version 5 format.
Convert a Version 1.4 Aggregate and a v4 Directory Using
zfsadm convert -path
We used the zfsadm convert –path on a mounted version 1.4 aggregate to convert a
directory to an extended (v5) directory. This converted the aggregate to a version 1.5
aggregate and converted the directory indicated in the -path to an extended (v5) directory.
We mounted a version 1.4 aggregate.
$ mount -t zfs -f OMVSSPN.PET3.ZFS.FS /pet3
Using zfsadm fileinfo, we see that the directory is a version v4.
$ zfsadm fileinfo -path /pet
path: /pet
***
global data
***
fid
83,1
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
dir name count
na
dir tree status
na
file format bits
na,na,na
file cver
na
direct blocks
0x0000585D
indirect blocks
none
mtime
Jul 8 13:26:53 2013
ctime
Jul 8 13:26:53 2013
reftime
none
anode
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
701,5052
BLOCKED
755
0,0
0,0
N,N,N
none
11
4
9
na
na
na
Jul 21 18:57:59 2013
Jul 24 13:56:01 2008
Using zfsadm convert –path we converted the /pet3 directory to an extended (v5)
directory.
$ zfsadm convert -path /pet3
IOEZ00791I Successfully converted directory /pet3 to version 5 format.
Using the zfsadm fileinfo command we see that the /pet3 directory was converted to an
extended (v5) directory, and the aggregate was converted to version 1.5. The other v4
directories remained v4.
$ zfsadm fileinfo -path /pet3
path: /pet3
***
global data
***
fid
1,1
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
dir name count
6
dir tree status
VALID
file format bits
na,na,na
file cver
na
direct blocks
0x0000A710
indirect blocks
none
mtime
Jul 26 14:07:24 2013
ctime
Jul 26 14:07:24 2013
reftime
none
anode
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
79,516
BLOCKED
777
0,0
0,0
N,N,N
none
4
5
4
na
na
na
Jul 26 14:50:48 2013
Jul 12 14:34:46 2002
Using the zfsadm aggrinfo command, with the –long option, we see that the aggregate
was converted to version 1.5.
$ zfsadm aggrinfo -aggregate OMVSSPN.PET3.ZFS.FS -long
OMVSSPN.PET3.ZFS.FS (R/W COMP): 1960807 K free out of total 1961280
version 1.5
auditfid E2E2F0F0 F7F909ED 0000
sysplex-aware
245100 free 8k blocks;
7 free 1K fragments
112 K log file;
56 K filesystem table
280 K bitmap file
Convert a Version 1.4 Aggregate on First Read-Write Using
converttov5
A version 1.4 aggregate can be changed to a version 1.5 aggregate on the first primary
read-write mount if IOEPRMxx option converttov5=on is set, or if the
CONVERTTOV5 MOUNT PARM is specified. The default is off. The aggregate is
changed to a version 1.5 aggregate and each existing directory is converted to an
extended (v5) directory as it is referenced.
The CONVERTTOV5 or NOCONVERTTOV5 specifies whether a zFS read/write file
system is assigned the converttov5 attribute. If it is assigned the converttov5 attribute
and the aggregate is a version 1.5 aggregate, zFS automatically converts directories from
v4 to extended (v5) as they are accessed. If the converttov5 attribute is assigned at
primary mount time, a version 1.4 aggregate is changed to a version 1.5 aggregate. If
automatic directory conversion for a directory fails, the conversion is not attempted again
until the file system is unmounted and mounted again. The converttov5 attribute can also
be assigned if the MOUNT option is not specified but the converttov5 specification in the
IOEFSPRM file is on when the file system is mounted or remounted. The default is
NOCONVERTTOV5. The CONVERTTOV5 parameter can also be assigned to a
mounted zFS file system.
We mounted a version 1.4 aggregate as read/write (RDWR) with the CONVERTTOV5
mount parameter. This converted the aggregate to a version 1.5 aggregate.
MOUNT FILESYSTEM('OMVSSPN.VER14.TO.VER15.ZFS') TYPE(ZFS)
MODE(RDWR) MOUNTPOINT('/zfspetmounts/ver14tover15')
PARM('CONVERTTOV5')
Since the file system was mounted with the CONVERTTOV5 mount parameter, it
shows as a version 1.5 aggregate using the zfsadm aggrinfo with the –long option
display.
$ zfsadm aggrinfo -aggregate OMVSSPN.VER14.TO.VER15.ZFS -long
OMVSSPN.VER14.TO.VER15.ZFS (R/W COMP): 1263 K free out of total 1440
version 1.5
auditfid E2E2F0F0 F1F41A4E 0000
sysplex-aware, converttov5
157 free 8k blocks;
7 free 1K fragments
112 K log file;
16 K filesystem table
8 K bitmap file
Using the df and D OMVS commands we can see the CONVERTTOV5 mount
parameter.
$ df -vkP
/zfspetmounts/ver14tover15
Filesystem
1024-blocks
Used Available Capacity Mounted
on
OMVSSPN.VER14.TO.VER15.ZFS 1440
177
1263
13%
/zfspetmounts/ver14tover15
ZFS, Read/Write, Device:62948, ACLS=Y
CONVERTTOV5
File System Owner : J80
Automove=Y
Client=N
Filetag : T=off
codeset=0
Aggregate Name : OMVSSPN.VER14.TO.VER15.ZFS
d omvs,f,name='OMVSSPN.VER14.TO.VER15.ZFS'
BPXO045I 13.33.15 DISPLAY OMVS 951
OMVS
0012 ACTIVE
OMVS=(00,J8)
TYPENAME
DEVICE ----------STATUS----------- MODE
ZFS
62948 ACTIVE
RDWR
NAME=OMVSSPN.VER14.TO.VER15.ZFS
PATH=/zfspetmounts/ver14tover15
MOUNT PARM=CONVERTTOV5
OWNER=J80
AUTOMOVE=Y CLIENT=N
MOUNTED
LATCHES
08/14/2013 L=1422
13.29.00
Q=1422
We used zfsadm fileinfo to check the directories. Fileinfo accesses the v4 directories,
and automatically converts them to extended (v5) directories.
$ zfsadm fileinfo -path /zfspetmounts/ver14tover15/origv14dir1
$ zfsadm fileinfo -path /zfspetmounts/ver14tover15/origv14dir2
$ zfsadm fileinfo -path /zfspetmounts/ver14tover15
With zfsadm fileinfo all show as extended (v5) directories.
...
object genvalue
...
0x00000000
dir version
5
Convert an Aggregate and All Directories Using IOEFSUTL
We converted a version 1.4 aggregate to a version 1.5 aggregate, converting all
directories to extended (v5) directories using IOEFSUTL converttov5. This requires the
file system to be unmounted and executed on z/OS V2R1.
We needed to ensure that the version 1.4 file system was unmounted.
UNMOUNT FILESYSTEM('OMVSSPT.VER.CONVERT.ZFS') IMMED
We executed a batch job to run IOEFSUTL converttov5. Here are Excerpts from the
JCL.
…
//CONVERT EXEC PGM=IOEFSUTL,REGION=0M,
// PARM=('converttov5 -aggregate OMVSSPT.VER.CONVERT.ZFS')
…
Here is an example of the results.
IOEZ00559I zFS IOEFSUTL: Initializing z/OS
zFS
Version 02.01.00 Service Level z150127 - HZFS410.
Created on Fri Mar 1 10:21:13 EST 2013.
Address space asid x44
IOEZ00760I No IOEZPRM DD specified. Parmlib search being used.
IOEZ00810I Successfully changed aggregate OMVSSPT.VER.CONVERT.ZFS to
version 1.5.
IOEZ00800I Conversion has processed 7 of 7 objects in the anode table.
IOEZ00803I 4 directories were found, 4 converted, 4 directory pages
converted to 4 directory pages.
IOEZ00808I Successfully converted all directories in aggregate
OMVSSPT.VER.CONVERT.ZFS to version 5.
Note: aggrversion_only was not defined, so all directories were converted to extended
(v5) directories also.
We then mounted the file system and used zfsadm fileinfo and zfsadm aggrinfo with the
–long option to see if it was converted to a version 1.5 aggregate and all the directories
were converted to extended (v5) directories.
MOUNT FILESYSTEM('OMVSSPT.VER.CONVERT.ZFS') TYPE(ZFS)
MODE(RDWR) MOUNTPOINT('/pet')
$ zfsadm fileinfo -path /pet
path: /pet
***
global data
***
fid
1,1
length
8192
1K blocks
8
uid,gid
0,0
dir model acl
0,0
user audit
F,F,F
set sticky,uid,gid
1,0,0
object type
DIR
object genvalue
0x00000000
dir name count
5
dir tree status
VALID
file format bits
na,na,na
file cver
na
direct blocks
0x00001781
indirect blocks
none
mtime
Mar 18 13:47:07 2013
ctime
Mar 18 13:47:07 2013
reftime
none
anode
format
permissions
access acl
file model acl
auditor audit
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
703,516
BLOCKED
356
0,0
0,0
N,N,N
none
5
5
3
na
na
na
Mar 18 13:48:07 2013
Mar 18 13:30:42 2013
$ zfsadm fileinfo -path /pet/origv4dir
path: /pet/origv4dir
***
global data
***
fid
2,1
anode
703,768
length
8192
format
BLOCKED
1K blocks
8
permissions
775
uid,gid
0,0
access acl
0,0
dir model acl
0,0
file model acl
0,0
user audit
F,F,F
auditor audit
N,N,N
set sticky,uid,gid
0,0,0
seclabel
none
object type
DIR
object linkcount
2
object genvalue
0x00000000
dir version
5
dir name count
2
dir data version
0
dir tree status
VALID
dir conversion
na
file format bits
na,na,na
file charset id
na
file cver
na
charspec major,minor
na
direct blocks
0x000018F9
indirect blocks
none
mtime
Mar 18 13:37:28 2013
atime
Mar 18 13:37:28 2013
ctime
Mar 18 13:37:28 2013
create time Mar 18 13:37:28 2013
reftime
none
$ zfsadm fileinfo -path /pet/dirfromz1when14
path: /pet/dirfromz1when14
***
global data
***
fid
4,1
anode
length
8192
format
1K blocks
8
permissions
uid,gid
0,0
access acl
dir model acl
0,0
file model acl
user audit
F,F,F
auditor audit
703,1272
BLOCKED
775
0,0
0,0
N,N,N
set sticky,uid,gid
0,0,0
object type
DIR
object genvalue
0x00000000
dir name count
3
dir tree status
VALID
file format bits
na,na,na
file cver
na
direct blocks
0x00001EDE
indirect blocks
none
mtime
Mar 18 13:47:29 2013
ctime
Mar 18 13:47:29 2013
reftime
none
seclabel
object linkcount
dir version
dir data version
dir conversion
file charset id
charspec major,minor
atime
create time
none
2
5
1
na
na
na
Mar 18 13:48:23 2013
Mar 18 13:47:07 2013
$ zfsadm aggrinfo -aggregate OMVSSPT.VER.CONVERT.ZFS -long
OMVSSPT.VER.CONVERT.ZFS (R/W COMP): 71175 K free out of total 72000
version 1.5
auditfid D7F2E4E2 F6F11C30 0000
sysplex-aware
8896 free 8k blocks;
7 free 1K fragments
720 K log file;
40 K filesystem table
16 K bitmap file
Convert a v4 Directory Using Copy (cp)
We mounted a version 1.4 aggregate, converted it to a version 1.5 aggregate, and then
used copy (cp) to create a copy of an existing v4 directory. It created the target directory
as an extended (v5) directory.
Note: The move (mv) command does not create a new directory if the target is in the
same parent directory and file system, thus the directory remains the same version. If the
target is in a different version 1.5 file system, and the directory is created as a result of
the move, the v4 directory will be converted to an extended (v5) directory.
We mounted a version 1.4 aggregate.
$ mount -t zfs -f OMVSSPN.ZFSFMT.ZFS /mnt1
Using zfsadm aggrinfo, we see it is a version 1.4 aggregate.
$ zfsadm aggrinfo -aggr OMVSSPN.ZFSFMT.ZFS -long
OMVSSPN.ZFSFMT.ZFS (R/W COMP): 559 K free out of total 720
version 1.4
auditfid E2E2F0F0 F1F70808 0000
sysplex-aware
69 free 8k blocks;
7 free 1K fragments
112 K log file;
16 K filesystem table
8 K bitmap file
Using the zfsadm convert command we converted the aggregate to a version 1.5
aggregate and verified with zfsadm aggrinfo –long and zfsadm fileinfo.
$ zfsadm convert -aggrversion OMVSSPN.ZFSFMT.ZFS
IOEZ00810I Successfully changed aggregate OMVSSPN.ZFSFMT.ZFS to version
1.5.
$ zfsadm aggrinfo -aggr OMVSSPN.ZFSFMT.ZFS -long
OMVSSPN.ZFSFMT.ZFS (R/W COMP): 551 K free out of total 720
version 1.5
auditfid E2E2F0F0 F1F70808 0000
sysplex-aware
68 free 8k blocks;
7 free 1K fragments
112 K log file;
16 K filesystem table
8 K bitmap file
Use zfsadm fileinfo to display the directory.
$ zfsadm fileinfo -path /mnt1/dir1
...
object genvalue
0x00000000
dir version
4
...
We tried to convert by using the move (mv) command for a directory in the same parent
directory and file system. However, this did not cause the directory to be converted to an
extended (v5) directory.
$ mv
/mnt1/dir1 /mnt1/dir2
$ zfsadm fileinfo -path /mnt1/dir2
...
object genvalue
0x00000000
dir version
4
...
We used copy (cp) to convert the target directory. This caused the target directory to be
converted to an extended (v5) directory.
$ cp -r
/mnt1/dir2 /mnt1/dir1
$ zfsadm fileinfo -path /mnt1/dir1
...
object genvalue
0x00000000
dir version
5
...
We converted by using the move (mv) command with the source being a v4 directory and
the target being a new directory in a different version 1.5 file system. This caused the
source v4 directory to be converted to an extended (v5) directory at the target location.
With /mnt1/dir1 as a v4 directory and using a target directory in another version 1.5 file
system that does not exist (/pet/dir1), we issued the following:
$ mv -r /mnt1/dir1 /pet3
$ zfsadm fileinfo -path /pet3/dir1
...
object genvalue
...
0x00000000
dir version
5