Understanding zFS disk space allocation

Unlike releases prior to z/OS® V1R13, data is not stored in 1 K fragments. Instead, the data is stored in 8 K blocks. Releases z/OS V1R13 and later can read data that is stored in fragments; however, when the data is updated, it is moved into 8 K blocks. Note that because previous releases of zFS can read an 8 K block that is not full, no toleration support is required on those systems. Also, in previous releases, when zFS stored data in fragments, data from multiple files typically resided in separate 8 K blocks.

However, there are certain cases when z/OS V1R13 and later will require more DASD space than zFS in previous releases. For example, if every file in the file system were 1 K or less, zFS on z/OS V1R13 or later releases could require up to twice as much DASD storage as previous releases. As a second example, because HFS uses 4 K blocks to store data and zFS uses 8 K blocks, if every file in the file system were 4K or less, zFS R13 could require up to twice as much DASD space to store these files. As another example, if the file system contained 1000 files that are 1 K in size, zFS in z/OS V1R13 and later releases could take a maximum of 10 cylinders more than zFS in previous releases. Typically, however, any increase in the DASD storage used by zFS V1R13 and later releases will be negligible. For example, the R13 version root file system that is copied using zFS R13 takes approximately 2% more space than the same file system copied using zFS R11. Note that zFS releases z/OS V1R13 and later packs multiple ACLs and symbolic links into an 8 K block, which previous releases did not do.

Another result of moving fragments into 8-KB blocks is that the following situation can occur:

A zFS file system is full, and
It is zFS-owned on a V1R13 or later system, and
It has no secondary allocation specified, or cannot extend because there is no space on the volume, and
You try to remove some files in order to free up some space, but the remove fails due to return code ENOSPC (133)

This failure can occur because you are trying to remove an entry from a directory that was created before z/OS V1R13 and is smaller than 7 KB, so it is stored in fragments. But the file system is zFS-owned on a z/OS V1R13 or later system and needs a free 8-KB block to do the remove. To resolve this problem, you must explicitly grow the file system in order to make free 8-KB blocks available. You can do this even if the zFS file system data set does not have a secondary allocation size specified. Free space on the volume is required. For example:

# rm /service6/testdir2/filea
rm: FSUM9195 cannot unlink entry "/service6/testdir2/filea":
EDC5133I No space left on device.
# zfsadm aggrinfo PLEX.JMS.AGGR006.LDS0006
PLEX.JMS.AGGR006.LDS0006 (R/W COMP): 21 K free out of total 7200
# zfsadm grow PLEX.JMS.AGGR006.LDS0006 7920
IOEZ00173I Aggregate PLEX.JMS.AGGR006.LDS0006 successfully grown
PLEX.JMS.AGGR006.LDS0006 (R/W COMP):741 K free out of total 7920
# rm /service6/testdir2/filea
#

If you need to add a volume, you can add one using the IDCAMS ALTER command with the ADDVOLUMES option. For more information, see Adding volumes to a compatibility mode aggregate.

A zFS aggregate is an array of 8-KB blocks. Three special objects are present in all zFS aggregates. These objects take up space in an aggregate, which means that space cannot be used for user files:

Log file: Records metadata changes. By default, its size is 1% of the disk size. However, it will never be smaller than 14 blocks and it will never be larger than 16,384 blocks (128 MB).
Bitmap: Lists the blocks that are free on disk. The file size depends on the size of the aggregate.
Aggregate File System List: Describes the file systems that are contained in the aggregate. For compatibility mode aggregates it is usually only one 8-KB block.

The zfsadm aggrinfo command shows aggregate disk space usage. This is based on the number of 8-KB blocks. It subtracts the space that is reserved for the previous three objects in its calculations (and tells you this in the output). The zfsadm aggrinfo command shows output in units of 1-KB blocks. If you use the -long option of the zfsadm aggrinfo command, it shows the number of free 8-K blocks, the number of free 1 K fragments and the size (in K) taken up by the log file, the file system table, and the bitmap.

The zFS threshold monitoring function aggrfull reports space usage based on total aggregate disk size. It incorporates the space for the above three special objects when showing total disk space and amount that is used on disk in its messages. The aggrfull message shows units in 8 K blocks.

The zfsadm aggrinfo command shows the free space and the total aggregate size in 1-KB units.

The df command shows the file system free space, but because the df command shows things in 512-byte units, usually the df output for zFS is exactly twice the numbers that are shown for zfsadm aggrinfo.

zFS stores files on disk in one of three ways:

inline: If the file is 52 bytes or less, it is stored in the same data structure on disk that holds the file status (such as owner, size, and permissions). A file 52 bytes or less takes no extra disk space.
fragmented: On systems before z/OS V1R13, if the file is 7 KB or less and has never been larger than 7 KB, zFS stores it in 1-KB fragments; as such, it is stored in part of an 8-KB block. Multiple small files can share the same 8-KB block on disk. On z/OS releases z/OS V1R13 and later, zFS no longer stores files in 1-KB fragments.
blocked: On systems before z/OS V1R13, if the file is over 7 KB, it is stored in one or more 8-KB blocks. On releases z/OS V1R13 and later systems, if a file is over 52 bytes, it is stored in one or more 8-KB blocks.