Businesses, governmental organizations and other entities are increasingly saving large volumes of data necessary for daily operations. This data represents a significant asset for these entities. Consequently, data loss, whether accidental or caused by malicious activity, can be costly in terms of wasted manpower, loss of goodwill from customers, loss of time and potential legal liability. To ensure proper protection of data for business and legal purposes (e.g., to ensure quick recovery of data in the event of a disaster, to comply with document retention requirements, etc.), these entities often back up data to a physical media, such as magnetic tapes or optical disks on a regular basis.
Traditional backup systems placed an application server, backup server, source device, destination device and a local area network (“LAN”) in the data path of backup operations. Under these systems, the LANs were becoming overburdened by the amount of data being copied. Often, the backup window (the period in which data unavailable for normal operations in order to permit backup) was too short to achieve a complete backup of data. Accordingly, many entities implemented Storage Area Networks (“SAN”) to relieve the burden of mass data storage and backup from the LAN, freeing the LAN for more immediate data storage and manipulation operations. In SANs, data from multiple machines on a network may be backed up to a remote media library. Centralized data backup allows storage problems to be identified at one location and has the advantage of increased efficiency.
One example of a media library commonly used in enterprise backup systems is a magnetic tape library. In a typical magnetic tape library, tapes are contained in cartridges and the tape library contains multiple cartridge slots in which tape cartridges can be stored. The tape cartridges are physically moved between cartridge slots and tape drives by a robot. The robot is controlled by access commands received from the host devices on the network. When specific data is required, the host device determines which cartridge slot contains the tape cartridge that holds the desired data. The host device then transmits a move-element command (e.g., the SCSI “move medium” command) to the robot and the robot moves the tape cartridge, mounting the cartridge in the appropriate tape drive.
The Linear or Linear Tape File System (LTFS) Format Specification by IBM and the LTO Program (hereby fully incorporated by reference in its entirety for all purposes) defines a file system for LTO-5 tapes, LTO-6 tapes and may be extended to other tapes using an eXtensible Markup Language (XML) schema architecture. This file system support allows the use of an LTFS-formatted tape as if it were a file system. Files and directories may appear in a directory listing, files may be dragged and dropped from tape, data may be accessed at the file level, etc.
Consequently, while it previously was necessary to make use of a backup application to write and read tapes, the introduction of LTFS has simplified the storing and retrieval of files on tape by reducing such operations to a copy. Furthermore, any operating system that includes LTFS support can mount LTFS for a properly formatted tape and read and write the files thereon.
Before an LTFS tape can be used, it must be mounted in an LTFS-compatible tape drive, and the LTFS filesystem must be mounted. In this disclosure, the terms “file system” and “filesystem” may be used interchangeably. Once the LTFS filesystem has been mounted, files on the tape can be accessed in the same manner as files in other filesystems (e.g., written, read, dragged and dropped, etc.). When the tape is no longer needed, the LTFS filesystem is unmounted, and then the tape can be removed from the tape drive.
In some systems, the LTFS-compatible tape drives are accessed using Unix/Linux commands. The mounting and unmounting of the LTFS filesystem in these systems are asynchronous operations. In other words, when a mount or unmount command is issued, the operation is initiated, but the user does know when the operation is complete—no notification of the completion is provided by the operating system, and the operation does not complete with known timing. If a command which is dependent upon the completion of the mount or unmount operation is issued before the mount or unmount operation is completed, the subsequently issued command will fail. This problem is normally resolved by simply retrying the subsequent command. After some number of retries, the mount or unmount operation will presumably have had sufficient time to complete, and the subsequent command will be successful.
When the mount/unmount and subsequent commands are being manually issued by a user, the solution of retrying the subsequent commands may be sufficient. In the case of automated systems (e.g., media library interface/management systems) that issue these commands, however, there are some problems with this solution. For example, when an automated, synchronous system retries the subsequent command before the preceding mount/unmount command is complete, an error message may be generated—repeated retries may result in a large number of error messages. A user may interpret the large number of error messages as an indication of a malfunction in the system, rather than a normal and expected result of the retries, and may consequently feel that it is necessary to interrupt operation of the system to determine the source of the errors. Additionally, the retries increase the resource usage of the system, and the delays between completion of the asynchronous commands and the succeeding retries reduce the efficiency of the system.
It would therefore be desirable to provide a mechanism for enabling a synchronous media library interface/management system to perform or interface with asynchronous mount and unmount operations in a way that eliminates the need to continually retry commands that follow these operations and increases the efficiency of the system.