| Previous | Table of Contents | Next |
To ensure that when these new technologies were ready we could slip them into the System/38 with no disruption, we kept all knowledge of disks below the MI.7 But the requirement that software not know about disks above the MI caused some problems for us. (Be aware that when the disk-management component writes an object to disk, it usually tries to spread the object across multiple disk drives. This is especially true for large objects. The idea behind this spreading is to improve performance and disk utilization. By spreading the object across several disk arms, the time required to read or write the object can be reduced because the disk operations can take place in parallel. Even today, disks on an AS/400 are not treated as I/O devices. They are treated as memory.)
7Obviously, however, the “new” technologies never lived up to their expectations and disk storage will likely be with us for a long time.
If a disk drive on the System/38 failed and could not be recovered, no one and nothing above the MI knew what was on a specific disk. After the failed disk had been repaired or replaced, the entire disk subsystem had to be reloaded from the last tape backup — not a good situation. So we decided some knowledge and control of disks had to exist in OS/400, and we created auxiliary storage pools (ASPs).
An ASP is a collection of disk devices. All the disk storage in a pool appears to be a single, contiguous area in memory. Individual devices are not visible. The minimum size to an ASP is one disk arm, and the total disk storage on an AS/400 can be divided into a maximum of 16 ASPs.
The first ASP is always the system ASP. OS/400 and certain types of system objects controlled by OS/400 must be in the system ASP. Up to 15 user ASPs can be defined. Any object that does not have to be in the system ASP can be put into any user ASP, but the entire object must fit. Objects cannot cross an ASP boundary.
Because disk storage is divided, any disk failure is isolated within a single ASP. This can greatly reduce the recovery time by minimizing the amount of disk that has to be reloaded. Certain types of objects, such as journal receivers, also can be isolated from other parts of the system, thereby improving recovery options. The disk-management component of SLIC handles ASP management.
All objects are composed of one or more nonoverlapping segments. When a segment is created, several characteristics of the segment must be specified. One of these is the segment’s initial size. Disk management allocates the number of pages for the segment based on this initial size. As we saw in Chapter 5, the autoextend bit in the segment header indicates whether the segment can be extended. If it can, the segment can grow up to the 16 MB limit for a segment.
When a new segment is created, disk space is allocated as one or more disk extents. A disk extent is a set of contiguous 520-byte sectors on a disk device. The minimum number of sectors in an extent is eight, because the smallest memory size that can be allocated is a 4K page. The number of pages in an extent is always a power of two. Thus, the individual extent sizes available are 4, 8, 16, 32, and 64K, continuing up to 16 MB.
Using extents simplifies the management of free space on the disk, because extents limit the number of fragment sizes. Auxiliary storage management uses a machine index to keep track of the free extents on each disk and combines contiguous smaller extents into larger extents. This recombination of small blocks of free space into larger blocks is very simple and fast. Because each extent is always half of the next larger extent size, when any extent is freed, a simple check can be made to determine whether the other half is also free. If so, the two are combined into a larger extent. The process continues until no further recombination is possible.
A virtual segment can be made up of several physically discontiguous extents on disk. This is especially true if a segment is extended. When a segment needs to be extended, storage management finds a combination of extents large enough to hold the requested number of pages. These extents may even be on different disk devices, although they will always be in the same ASP.
To net all this out:
Earlier, we saw that segments are created as permanent or temporary. A temporary segment also can be created as part of an access group. A few additional words are in order for access groups. The purpose of an access group is to enhance the performance of reading into and writing out of memory the temporary segments associated with a user job in the system. A typical user job may have dozens of temporary objects associated with it. If these were treated as ordinary objects, each would occupy one or more temporary segments. Each segment would have at least one extent. If we wanted to move all of a job’s pages from memory to disk, it would take at least one I/O operation per extent. The same would be true when we wanted to read the job’s pages back into memory.
An access group is a system object that was defined to eliminate most of this performance overhead. An access group consists of two segments. The first segment, the base segment, contains a table of contents (TOC). The second segment is a data segment. Each TOC entry contains the effective address of a unique data page in the data segment.
When a temporary object is created within an access group, its segments will be assigned the next available spaces in the access group data segment and the TOC will be updated. In this way, several physically small temporary segments can be packaged within the same data segment extent on disk, and all can be read or written with a single I/O operation.
Note that an access group works only for physically small objects and their small segments. All segments have 16 MB of address space, but most temporary segments for a job occupy only a few pages of physical memory. Access groups work very well for these types of small temporary segments. There are no access groups for permanent objects because permanent objects tend to be larger in size, which defeats the advantage of an access group.
| Previous | Table of Contents | Next |