Introduction

IBM's System z has been around for a long time – since the mid 1960s. Since this time, the mainframe has evolved and adapted new technology while still maintaining complete backward compatibility. Most people are unaware that services they use everyday rely on mainframe technology in order to function – banks, insurance companies, universities, various entities within the transportation industry, and so on.

Due to their size (vast) and cost (astronomical), System z does not see as much use among individuals as other architectures such as x86, arm, etc. So if you ever do find yourself plunged into the world of mainframes, it can be confusing for a while as you attempt to sort out the various idiosyncracies. One thing you'll notice right away is that storage is quite different from what you're used to seeing, with a lot more acronyms. The aim of this post is to give a very brief overview of System z storage, so if you ever find yourself having to interface directly with an IBM mainframe someday, you'll hopefully be a little less lost.

Channel I/O

IBM's System z employs channel I/O, a high performance I/O architecture. This means that special hardware exists to specifically handle I/O bound tasks, independent of the CPU(s). All devices are connected to the channel, which itself is a programmable device. I/O operations which the channel must execute are called a channel program. Channel programs contain specific I/O instructions (channel command words, or CCWs) such as "read", "write", or "seek".

DASDs

The standard "disk" found on a mainframe is a DASD (daz-dee), a Direct Access Storage Device. IBM has done a significant amount of work over the years to add DASD support in the kernel and various other applications (parted, anaconda). There are various types of DASDs. They all vary to some extent in their disk geometry, which will be discussed briefly.

Physically, a DASD is a set of circular platters like in ordinary disk drives you are probably more familiar with. If you split the surface of each platter into concentric circles, these are called tracks. Corresponding tracks on each platter make up a cylinder. Tracks themselves can be divided into blocks.

The different types of DASDs can be identified by their four-digit device type number, and often, an additional suffix to note different models among the types, e.g. 3390-1, 3390-2, and 3390-3. The differences among each type are among the number of cylinders, tracks per cylinder, channel speed, seek time, etc. By far, the most popular type of DASD today is the 3390-3, which has 3339 cylinders.

In the past, FBA (Fixed Block Architecture) DASDs were more common. FBA is the equivalent to LBA in the non-mainframe world. The blocks are all a fixed size. Today, actual FBA DASD hardware is no longer available, although FBA DASDs can be simulated from within a mainframe operating system.

In contrast, CKD DASDs can have different block sizes. Each block is composed of a count block, a data block, and sometimes a key block. The count block contains the size of the data block, and the key is a string, which can aid in the search for a data record via some channel command word. ECKD DASDs are more modern; they are Extended CKD DASDs, which means there is support for extra, high-performance functionality. Most DASDs in use today are ECKD. Within Linux, (E)CKD DASDs have three different formats which are recognized by the kernel – LDL (Linux Disk Layout), CDL (Compatibility Disk Layout), or CMS.

LDL (volume label LNX1) is rarely used, and if it were there would be one immutable partition on the disk. LDL is a format that is not officially supported by Red Hat in the installer, although the kernel does detect LDL DASDs. In contrast to CDL, there is no VTOC present on LDL DASDs, and it is not strictly necessary that a volume label be assigned.

CDL (volume label VOL1) is the default format; this has been the industry standard for well over at least a decade at the time of writing this post. The first few tracks of CDL DASDs contain information about the volume label and a Volume Table of Contents (VTOC), a structure which contains pointers to every data set on the DASD. On Linux, these data sets contain partition information.

A CMS DASD (volume label CMS1) has a CMS file system on it. A CMS DASD is treated exactly like an LDL DASD on Linux, so there can only be one partition on this type of disk.

A DASD can also be "unformatted", which means it has no format or volume label. DASDs in this state are completely unusable on Linux and must be low-level formatted using the "dasdfmt" command from the s390utils package first.

Other Devices

An EDEV is an Emulated Device. These are zFCP (z Fiber Channel Protocol) devices masquerading as FBA volumes. To use one under Linux, you would first fabricate an EDEV in z/OS (a mainframe operating system). When you boot into Linux, it should appear and behave as an FBA DASD.

An EAV is an Extended Address Volumes. These are ECKD DASDs with over 65520 cylinders. Although I am not an authority on mainframe storage, in my experience thus far interacting with our s390x at Red Hat and working on numerous customer bug reports, EDEV and EAV are not commonly used.

zFCP devices are essentially SCSI devices operating via FCP (Fiber Channel Protocol).

On z/OS, one can also construct minidisks if they wish. A minidisk is some range of continguous cylinders on a DASD.

Final Notes

These days, mainframe storage is almost entirely virtualized. Most mainframes consist of some giant RAID configuration utilizing standard PC disks which emulate DASDs. If this confuses you, and you wonder why doesn't IBM just use standard disks – remember that everything must be backware compatible, back to the days when actual DASD hardware was used. Also, IBM's most popular OS for its mainframe, z/OS, can not run on standard disks.

Thanks to the IBM Knowledgebase, IBM Redbooks, and various posts from the S390@marist.edu mailing list for knowledge I learned previously and/or had to look up for the purposes of this post.