You are currently on IBM Systems Media’s archival website. Click here to view our new website.

IBM i > STORAGE > DISK

Moving Data to Solid State Drives


If you’re thinking of installing solid state drives (SSDs) in the near future, you should take a look at the technical document, “Customer Use of SSDs.” There’s a lot of good information in there and I’m not going to repeat all of it, but I will reference it, so you might want to take a look at what’s in there before reading further. My real intention with this article is to point out some things not spelled out in the SSD doc that have caused confusion as well as add additional emphasis to some of the things the doc does say. But, what I’m not going to do is talk about whether or not SSDs will improve your performance or by how much. We have some good folks in Lab Services who can help you out on that.

PTFs Are Important

A lot of the support for SSDs has been provided by PTFs, and the technical document I referenced above contains a link to an updated list of those PTFs. I strongly suggest you make sure you apply them, ALL of them, before you start configuring SSDs on your IBM i. Early PTFs allowed you to move files to SSDs synchronously but locked your applications out of those files for the duration of the move, which could be a significant amount of time. To move this processing to the background, a set of PTFs were developed so the files being moved were locked for only a few seconds to figure out what needs to be moved, and then moves all that data using background tasks. This “asynchronous move” makes life easier for our customers who need access to that data 24-7. Interspersed with those PTFs are things we’ve improved and fixed. Some issues we discovered and fixed in conjunction with the “asynchronous move” PTFs were also issues with the older synchronous move PTFs, so you need the “asynchronous move” PTFs to get the fixes and improvements. But the point is, install ALL the PTFs.

What To Move and How

One of the first things you need to think about is how you want SSD storage managed. If you’re going to put all your SSDs in a dedicated ASP or IASP, with no spinning disk drives, then managing what does and does not go onto the SSD is as simple as managing what does and does not go into the ASP or IASP. But a lot of you are going to configure both SSDs and regular spinning disk drives in the same ASP or IASP, and you only want certain files on those SSDs. By default, SSDs are treated just like any other disk drive, which means you have no control of what lands on the SSD. Fortunately, we give you a “knob” that allows you to tell the OS to only put on SSD what you designate for SSD. The “knob” is one of the first things discussed in the technical doc I referenced.

Since support to move files onto (or off of) SSDs was delivered via PTFs, we don’t have an obvious way of reporting how far along in the “asynchronous move” process your files are. We’ll discuss this in more detail later, but there’s an easy, although sometimes confusing, way to see where your file is headed. Physical files are complex objects at the OS level. Within each physical file are one or more members. And how you move the members can cause some confusion. If you’re moving files using CL commands, your options are CHGPF (change physical file) and CHGPFM (change physical file member). On the face of it, it would seem they do pretty much the same thing, but there are some subtle differences. First, CHGPF affects ALL the members in the file. It also affects the preference for any new members added to the file later on. CHGPFM only affects the state of the specified member. And this is where we’ve seen some confusion. The easy way to see where your file is headed is using DSPFD (display file description), either green screen or via the GUI interface. There’s a field returned called UNIT, both for the “Database file attributes” section and for each “Member description” section of the DSPFD output. UNIT only indicates what your preference is, not where the data actually is.

The UNIT in the “Database file attributes” section only tells you what the preference is for members created in the future, not where your data is or is headed right now. Valid values for UNIT in this section are:

  • “*ANY”: Keeps file data OFF SSDs if you used the knob to only put marked data onto SSDs.
  • “255” or *SSD (new in V7R1): Mark data to be placed on SSD if space on SSD is available.

This is NOT changed if you use CHGPFM, because CHGPFM only affects the member.

It is the UNIT in the “Member description” section that tells you what the actual preference is for your specific member. The possible values are “*ANY” or “255”, although you may see “*SSD” in the future. And if you’ve been changing media preferences a bit, this is where you want to look to see what the media preference is for you file member, not in the “Database file attributes” section.

Those same nuances apply to CHGLF (change logical file) and CHGLFM (change logical file member).

Monitoring An Asynchronous Move

Now we’ll discuss how to assess how far along the “asynchronous move” is. At a high level, a way to see if things are moving is to use WRKDSKSTS, refreshing periodically. You should see storage on the SSD units increasing, and if you’ve added up the sizes of the objects you’re moving, then you should be able to figure out what percentage full to expect once the move is complete.

To see how much has actually moved on an object basis, you need to query QSYS2/SYSPARTITIONDISK or QSYS2/SYSPARTITIONINDEXDISK. This is described in the SSD technical doc. Be aware that if you’ve entered commands to move a number of files (or tables, indexes, etc.), it may take a while for things to complete. Even though some of the work gets done in parallel by background tasks, some things need to be serialized deep in the OS to make the “magic” happen. However, this serialization will not affect your access to the object. Also, any new data (records or keys) added to the file after you’ve altered the media preference will be written to SSDs. As a result, you may see SSD storage grow slowly for a file as new records are added, even though the background tasks have not started to move the original storage for the file.

So what’s that mean? Well, a couple of things can happen. For example, you might run the queries too soon and see that only some of your objects, or only parts of an object, are on SSD. That’s OK, check back later and see if things have changed. As long as things are moving to SSD, it’s likely just a long process to get things moved.

You might run the queries a few times and see that things have stopped moving, or that nothing has moved, or that things are moving very slowly. This could be the case when only newly allocated storage landing on SSDs. What’s going on here? Well, if you’re a bit savvy with the service tools, you can check the vlogs and that may give you some feedback. Remember, we provided this function via PTF, so we were limited in how we provide feedback. The vlogs to look for are 0600 8410, 0600 840C, 0600 840F, 0600 8409, 0600 840A and 0600 840B.

The 0600 8410 and 0600 840C vlogs indicate that the data within an object was successfully moved. The second “DUMP ITEM” within the vlog is the name of the object. But, if your object is a keyed physical file (which is different from a physical file with a logical file built over it), then under the covers, it is actually two objects, the data portion of the member and the access path, and you will see a vlog for each.

The 0600 840F, 0600 8409 and 0600 840A vlogs indicate a failure to move part or all of an object. For those vlogs, the second “DUMP ITEM” is again the object name. But there is another piece of useful information. The seventh “DUMP ITEM” is a reason code for the failure. Here are some common reason codes, what they mean, and what you can do about it:

  • 0005 – This is the most common reason we see for a failed move. This reason code means that some other task or process is already moving segments around. Most often, it’s something called the “sweeper,” which is discussed in the SSD technical document. The sweeper, and anything else that moves segments around, interferes with the task that is trying to move your objects. We’ll talk more about this a little later.
  • 0007 – Not enough free space. There simply isn’t enough SSD space configured in the object’s ASP to move all of the object to SSD.
  • 0009 – Something happened to an extent while it was being moved. Most likely, it was deleted. This can happen when you delete an object, but also when you clear a file or reorganize a file while it’s being moved.

Lastly, the 0600 840B indicates a general failure and you’re likely to find some TOLERATED EXCEPTION vlogs just prior to it. If you don’t have any other reason to suspect an issue with the object, ASP, or target media, this may require some investigation.

Dave Owen is a software engineer at IBM in Rochester, Minn. He’s been working in System Licensed Internal Code for System i focusing on features that aid in recovery, HA and performance for more than 15 years.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Gift-Wrapped and Delivered

IBM announces new storage solutions

Closing the Backup Window

V5R4 introduces virtual tape and its many backup benefits.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters