About 10 years ago, I took a tour of the computer operations facilities of one of the nation’s largest health insurance companies. The hardware I saw on this tour was impressive, to say the least. One of the most impressive parts of the tour was the tape room. This company had a room filled with shelves containing thousands of tapes. When a user required data from a tape, a robot would get the tape off the shelf and load it into a tape drive. When the user’s application finished using the tape, the robot would remove the tape from the drive, put the tape back on the shelf, and then go get another tape. Although I was completely intrigued by what I saw, the company’s data center was entirely mainframe based. I assumed I would never encounter such a cool toy in the world of PCs.
Well, here we are almost 10 years later, and not only are there plenty of mass storage devices available for use with PCs, Windows 2000 supports many of them—including robotic tape changers—natively. In this Daily Drill Down, I’ll introduce you to Windows 2000’s support for removable-storage devices. I’ll also explain some situations in which you may find yourself having to manually administer your removable-storage devices.
What’s a removable-storage device?
When you hear the term removable-storage device, it’s easy to think of a backup tape. Although backup tapes are certainly a type of removable storage, many other types are available as well. A removable-storage device is just about any type of storage media that can be removed from the PC and later reinserted. It can be something as simple as a CD-ROM or something as complex as a robotic tape library.
Right now, you may be wondering why we’ve devoted an entire Drill Down to administering removable-storage devices if such a device can be as simple as a CD-ROM. After all, when it comes to CD-ROMs, what’s to administer? Just take a CD out of the drive and put another CD in. However, there’s more to the process than meets the eye. Windows is designed to treat all removable-storage devices in the same way. This makes it possible for software developers to write applications that interact with removable-storage devices—without the developer having to know exactly what type of device is being used.
Of course, not all applications will work with all removable-storage devices. For example, you can’t expect an application that writes data to removable-storage devices to work with a read-only CD-ROM drive. However, Windows is designed in a way that the developers can write their applications to interact with a removable-storage device in whatever method is necessary. Windows can then interact with a system’s hardware and tell whether the hardware is capable of supporting the application. This method frees the developer from having to write device drivers for all of the various removable-storage devices.
Working with removable-storage devices
Obviously, for this method to work, Windows has to use some rules to control the way that an application can interact with the various types of removable-storage devices. To understand how Windows brokers the relationship between applications, removable-storage devices, and the end user, you need to know a bit more about the various components that make up a removable-storage device.
Before I get started explaining what makes up a removable-storage device, enter the command
at the Run prompt. When you do, you’ll see the Removable Storage console, as shown in Figure A.
|The Removable Storage console allows you to manage removable-storage devices.|
When you consider that this console is capable of managing an enterprise-size robotic tape library, you may be surprised to learn that this console is even available through Windows 2000 Professional. In fact, as I’m writing this Drill Down, I’m looking at the console screen on my laptop. However, remember that from an application’s standpoint, Windows 2000 treats all removable-storage devices the same. This means that as far as Windows 2000 is concerned, my laptop’s DVD-ROM drive is just as valid of a removable-storage device as a million-dollar robotic tape system.
Now that you have the Removable Storage console on screen, I’ll explain the components of a removable-storage system, and I’ll describe some of the rules these components use to interact with one another. As I do, you’ll be able to see some of these components in the console screen shown in Figure A.
The most basic component of any removable-storage system is the media. The media is the place where data is read from and/or written to. In Figure A, the media is a CD, but the media could be a tape, DVD-RAM, or any other type of removable-storage medium.
Windows 2000 organizes storage media by physical location. The media can either exist as offline media or as a media library. As you’ve probably already figured out, offline media is valid media that’s not currently accessible to the system. In the case of a CD, it would refer to a CD that isn’t mounted in the drive. In the case of a tape, it would refer to a tape that Windows has cataloged but that isn’t currently in the tape magazine or accessible to a robotic tape loader.
A library, on the other hand, is a collection of media that’s currently available to the system. Perhaps the best example of a library is a tape magazine. Since a tape drive would be able to access any tape in the magazine, the tapes in the magazine would be referred to as a storage library. Even a CD can be thought of as a library of one when it’s loaded into the CD-ROM drive.
Of course, any time you have a library that consists of more than a single media, other components will be necessary for switching between the individual media. As I explain these components, consider the case of a tape magazine. The most obvious characteristic of a tape magazine is that it contains slots for multiple tapes. While in this instance slots refers to tape holders in the magazine, a slot could also refer to a spot on the shelf in a robotic tape library.
Another requirement in a library is a drive that can read the media. The drive could be a tape drive, a CD-ROM drive, or whatever. A magazine also requires at least one transport. A transport is the mechanism that physically moves the media from the slot to the drive. With a tape magazine, the transport would be the mechanism that lifts the tape magazine up and down. In a robotic tape library, the transport would be the robot.
As you look at Figure A, you’ll notice a section toward the top of the console called Media Pools. Media pools are a collection of a common type of media. For example, a media pool would be made up entirely of tapes, or entirely of CDs, or some other media. You can’t mix media types in a media pool. A media pool can contain multiple libraries, however. Let’s suppose your server contains two separate tape drives with magazines. Although each magazine is considered an independent library, a media pool can contain both magazines, assuming they use the same type of media.
Sometimes an application may need to pull data from multiple sources. If you create a media pool, it’s possible for a single application to pull data from several libraries without the application having to use a lot of extremely sophisticated code. A media pool can even contain other media pools.
Another purpose of a media pool is to control the permissions to the various libraries it contains. These permissions control access to the media itself. They dictate who can access a library, switch media within a library, allocate media for their own use, and so forth. These permissions don’t affect the actual data on the media; they apply only to the behavior of the media itself.
Beneath the media pools you’ll see containers labeled Free, Import, and Unrecognized. These particular containers are referred to as system pools because they are media pools that were created by the system. The system pools contain media that isn’t currently in use. The Free pool contains media that is available to any application. Applications can use media from the Free pool for storage, and they can also return media to the Free pool if the media is no longer needed.
The Import pool is used to store media that’s readable but foreign to the system. For example, suppose you created a tape on a different system and then loaded the tape into a tape drive on the system you use to manage your removable storage. If Windows is able to read the tape’s format, it will discover that the tape was created by a different system. Therefore, the tape will be placed in the Import pool so that you can later determine what to do with the tape.
Finally, media that’s unreadable is placed in the Unrecognized pool. There are several situations in which a media might end up in the Unrecognized pool. For example, if you insert a blank tape into a tape drive, the blank tape would be moved to the Unrecognized pool until it had been formatted and cataloged by the system. Likewise, if you create a tape on another system and then try to read the tape on this system but the format is incompatible, Windows won’t be able to read the tape and will therefore place it into the Unrecognized pool.
As you probably know, removable-storage devices can sometimes be slow to respond to a command. Furthermore, at the time a command is issued, the drive might be busy servicing another request. To prevent requests from being ignored, any time an application has to interact with a removable-storage device, the application’s request is placed into a work queue. The commands in the work queue are stored in sequence and are gradually processed as the removable-storage device becomes available.
Sometimes an administrator or an operator may need to manually interact with a removable-storage device. For example, a drive might fail and have to be taken offline, or maybe a new cartridge needs to be placed into the media library. Whatever the reason, whenever someone has to manually interact with the removable-storage device, the request is placed into the Operator Requests folder. Each request is then flagged with a status. The status is initially Submitted, but the status will change to either Refused or Completed as Windows tries to service the request.
Mass removable-storage devices are no longer limited to mainframe environments. In this Daily Drill Down, I explained how Windows 2000 supports removable storage devices. In a future Drill Down, I’ll discuss some situations in which you may have to manually interact with removable-storage devices.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.