The IT industry is decisively moving away from traditional hard disk drives (“platters”) in favor of Flash-based solid-state drives (SSDs). It’s a welcome change; it makes much more sense to circulate only electrons instead of disks of metal with electrons on them. The major benefit is, of course, speed—these SSDs just fly! SSDs are replacing traditional disks on laptops, desktops, and in the data center, too. They’re already running in many of the newer IBM i operating systems out there.
Sure, fast access to data is great, but how well do SSDs fare when it comes to the other big question in disk management: “Why is my disk over 95 percent full?”
The answer? They don’t make any difference at all! With a faster technology, your disk just fills up faster. In terms of effective disk management, you’ll still need to stay one step ahead of disk use, be it on SSDs or otherwise.
If you ignore ancillary things like licensed internal code (LIC) storage or main dump storage which, in the course of ordinary operations, require zero management, you’re left with the things that will consume disk space on your IBM i. These key elements include:
- Files and journal receivers in regular libraries
- Stream files in the IFS
- Temporary storage
- Objects in QTEMP libraries
- Spooled files
Let’s take a look at each.
Files and Journal Receivers
This one is straightforward. You have an application and it writes data to files. Lots of data. In fact, a whole bunch of little ones and zeros, measured out in gigabytes. We live in the age of big data and that data uses up disk. When files get journaled, this essentially creates embellished little copies of each record in the big files. The result? More disk usage.
Utilizing the IFS means being able to port those applications that were meant to run on AIX or Linux over to the good old AS/400 and run them there on that alien operating system. IBM even copied their file system to allow applications to run. So now you have stream files in the IFS, but how do you keep track of the disk they use?
Temporary storage is just an unnamed stretch in (single-level) storage that a program has requested. This happens, for example, when a program coded in C does a “malloc” or “calloc”, or when a Java program puts something into its heap space. This happens frequently. Because of single-level storage, that memory is always mapped to disk space. Always! And only if the operating system can find a bit of unused main storage (RAM) lying around, it will also use some of that, but essentially just for caching. So temp storage is always counted against free disk.
Objects in QTEMP Libraries
Each job has its own QTEMP library that other jobs are not allowed to peek into, but that library exists to house objects. Objects use up disk space. How do you check how much disk space is used up by objects in QTEMP libraries? It’s a very difficult task without the right tools.
Problems with spooled files are part and parcel of the IBM i administrator’s experience of managing the system. Applications create spooled files for users to review and, eventually, delete again. However, as so often is the case, the users don’t review them, much less delete them. For 90 percent of all spooled files, the user has no idea they exist. But they do, and they use up…can you guess?
That’s right. Disk.
What’s Consuming My Disk Space?
Robot Monitor helps administrators adopt a proactive approach to managing disk usage through real-time monitoring and alerts. The combination ensures full visibility over each of the critical disk-consuming areas mentioned above, and the necessary notifications to know when problems arise, so immediate action can be taken to resolve them. Robot Monitor keeps you informed about the largest objects and libraries on your system. This information is collected every few minutes, rather than once a day. You’re also able to monitor the size of objects of a particular type, name, and library in real time. Defining these relevant to your system’s requirements means fully customized control over the disk-consuming elements of your system. Real-time monitors can also be set up for journal receivers of a particular journal.
One of Robot Monitor’s greatest strengths is in providing an immediate view of what are otherwise hard to see values on current disk space use. Disk space used by QTEMP objects is the perfect example. Real-time insight through QTEMP monitoring replaces the alternative process that would involve going into WRKACTJOB or iSeries Navigator to find out the disk space used for every single job and QTEMP object. Such lengthy processes are an incredibly inefficient use of your time.
Temporary storage can be monitored in real time by job, user, subsystem, or entire system. This is especially useful when there are sudden surges in disk growth since a minimal amount of time is required to pinpoint the underlying issue. By adding thresholds to each monitor, you’re alerted in good time of any escalating disk use issues.
Using the drill-down features of Robot Monitor, an administrator would be able to see a temporary storage issue on the system and with a click determine the jobs running the highest use of temporary storage.
As disk speeds up, our response time recedes. Stay one step ahead of space issues with real-time monitoring of all critical disk-consuming areas of the system.