Translation device driver for translating between disk device driver and tape device driver commands

[0001] The subject matter of the present invention is related to U.S. patent application Ser. No. 11/026,079, now Pat. No. 7,167,326, issued Jan. 23, 2007, entitled: “Tape Drive That Supports Update-In-Place”, filed on even date herewith, assigned to the same assignee hereof, and which is incorporated herein by reference.

[0002] 1. Technical Field

[0003] The present invention relates generally to data processing systems and more particularly to storage devices and storage systems. Still more specifically, the present invention provides a translation device driver for translating between disk device driver commands and tape device driver commands in order to provide a block addressable virtual tape storage system that permits direct access and update-in-place access to its data.

[0004] 2. Description of Related Art

[0005] Tapes store data sequentially from the beginning of the tape to the end of the tape. A computer system cannot modify data stored in the middle of the data stored on the tape. A tape drive is an append-only storage system. Thus, data can be appended to the end of the data currently stored on the tape. Data stored in the middle of the data on a tape can be modified, but in this case, all of the data stored after the modified data will be invalidated. Therefore, data cannot be modified in the middle the tape and have the data located after the modified data remain usable. When data is replaced in the middle of the tape, all data on the tape located after the replaced data is invalidated.

[0006] Conversely, a disk drive storage system allows data to be updated in place. Thus, in a disk drive system, a block on the disk can be modified without invalidating other data stored on the disk drive.

[0007] Applications may be written assuming that the storage media the application will be using will be a storage system that permits direct access reads and writes as well as update-in-place. Disk drive storage systems permit direct access reads and writes as well as update-in-place. When an application attempts to access a disk drive storage system, the application makes a call to a file system in order to translate logical disk locations to physical disk locations. The file system is used to convert a request to access data at a logical disk location into a request to access the actual physical disk location where the requested data is physically stored.

[0008] A file system is a data structure that includes the names of files as well as the information needed to locate and access these files. The file system can be accessed directly, or randomly, for read and write operations. Furthermore, the file system supports update-in-place operations for each one of its blocks such that a write operation intended to update or replace the content of any block does not affect the content of any other block in the data structure.

[0009] The backing storage for this data structure must be a virtual or physical block storage device that supports direct access, i.e. random access, read, write, and update-in-place operations. Disk storage devices support these backing storage requirements and are typically used as devices to store a file system.

[0010] While tape storage is directly, i.e. randomly, accessible for reading and writing, there are no virtual tape storage devices that support an update-in-place capability. Virtual tape systems are known in the art. These systems are designed to operate using the same update rules as those used by physical tape storage systems or devices. Physical tape storage systems or devices do not support update-in-place data modification. Thus, known virtual tape systems do not permit update-in-place data modification.

[0011] Tape storage devices are unsuitable for storing a file system. Physical tape devices do not support update-in-place because of the inherent physical limitations of magnetic tape recording technology. All of the virtual tape implementations preserve the features and limitations of the physical tape drives and thus do not support update-in-place capability.

[0012] An attempt to rewrite or update a virtual or physical tape record location beyond the updated or rewritten record is not permitted because the data located after the updated or rewritten record is invalid after the update. This violates the update-in-place requirement for a file system data structure.

[0013] FIG. 1 is a block diagram of a data processing system 100 that uses a disk-based file system 102 to access a disk drive 104 through a disk driver 106 in accordance with the prior art. Individual independent blocks of data are stored on disk drive 104. Each block can be accessed and/or modified independently from all of the other blocks that are stored on disk drive 104. Disk drive access requests are sent to disk driver 106 which then forwards them to disk drive 104.

[0014] For example, as depicted by FIG. 1, a write command has been issued to write data to block 2000, and a write command has been issued to write data to block 504. When the data is written into these blocks, only these blocks are modified. Thus, when data is written to block 2000, only block 2000 is modified. The remaining blocks of data on disk drive 104 remain valid and unchanged.

[0015] In addition, FIG. 1 also illustrates a read command that has been issued to read data from block 77, a read command that has been issued to read data from block 241, and a read command that has been issued to read data from block 19.

[0016] Data can be read from and written to individual blocks in disk drive 104 without affecting the other blocks. For example, when the data in block 156 is modified, the remaining blocks are not affected. They remain valid regardless of where these blocks are located with respect to each other in disk drive 104.

[0017] FIG. 2 is a block diagram of a data processing system 200 that includes a tape application 202 that accesses a tape drive 204 through a tape driver 206 in accordance with the prior art.

[0018] Tape application 202 issues requests to access tape drive 204 first to tape driver 206 which then forwards the requests to tape drive 204. Data is stored in records on tape media 208 that is included within tape drive 204. When a particular record is to be accessed, tape media 208 must first be physically positioned to that record. When a record is to be read, tape media 208 is wound and rewound until that record is reached on tape media 208. The data can then be read from the record and transmitted from tape drive 204 back to tape driver 206.

[0019] Additional data can be stored in tape drive 204 by appending additional records to the end of the data that is already stored on tape media 208. Existing data that is already stored on tape media 208 can also be modified. When existing data is to be modified, tape media 208 is wound and rewound until the record that includes that data is reached on tape media 208. The new data can then be written to that record. In this case, all of the data that is stored on the tape after the modified record is invalidated.

[0020] For example, FIG. 2 illustrates reading a record, such as record 54, from tape media 208. When a record, such as record 54, is read, the data on tape media 208 is not affected. It remains valid. When a record, such as new record 58 is appended to the end of the existing records, the existing records are not affected. They remain valid. If, however, an existing record, such as record 55, is modified, the remaining records that are located after the modified record are invalidated. In this case, if record 55 is modified, records 56-58 are invalidated.

[0021] A file system generates a read/write command in a disk drive based format. Because the file system assumes that it is accessing a disk drive, the read/write commands are in a disk drive format. These commands are then transmitted to the disk driver as described above which then forwards the commands to the disk drive. When a tape application issues read/write commands, those commands are in a tape drive based format since the tape application assumes that it is accessing a tape drive. Thus, it is not known to replace a disk drive system with a tape drive system such that a file system is able to issue disk drive based commands that are used to access a tape drive system that is capable of processing only tape drive based commands.

[0022] Therefore, a need exists for a method and system that provides a translation device driver for translating between disk device driver commands and tape device driver commands in order to provide a block addressable virtual tape storage system that permits direct access and update-in-place access to its data.

[0023] A translation device driver apparatus and method are disclosed. A first type of request is received from a disk-based file system to access a first type of storage device. The first type of storage device permits direct access reads and writes and implements update-in-place data modification wherein individual blocks of data stored in the first type of storage device can be modified individually without invalidating data stored in any other blocks in the first type of storage device. The first type of request is translated into a second type of request. The second type of request is a request for a second type of storage device. The second type of storage device operates in append-only mode. The second type of storage device does not permit update-in-place data modification. The second type of request is forwarded to a storage system. The storage system is designed to be the second type of storage device. The storage system is modified to permit update-in-place data modification.

[0024] These and other features and advantages of the present invention will be described in, or will become apparent to those of ordinary skill in the art in view of, the following detailed description of the preferred embodiments.

[0041] A preferred embodiment of the present invention and its advantages are better understood by referring to the figures, like numerals being used for like and corresponding parts of the accompanying figures.

[0042] The present invention is a method and apparatus for translating between disk device driver commands and tape device driver commands in order to provide a block addressable virtual tape storage system that permits direct access for reads/writes and permits update-in-place access to its data. A translation device driver is provided that receives requests that are in a disk drive format. These requests are generated by a process or device, such as a file system, that believes it is accessing a block addressable storage device such as a disk drive. Thus, these requests specify a particular disk drive and particular block within the disk drive to be accessed. These requests are in a disk drive format.

[0043] The virtual tape system is designed to receive and process tape drive access requests. These tape drive access requests are in a tape drive format. The translation device driver receives the disk drive requests, translates the requests into a tape drive format, and then forwards the requests to a virtual tape system.

[0044] In addition to translating between a disk drive format and a tape drive format, the translation device driver translates the requested disk drive and block locations included within the disk drive request into a particular virtual tape drive and a record location within the virtual tape volume that is mounted on that virtual tape drive. Thus, the translation device driver maps disk drive locations that are requested by the file system to virtual tape volume locations where the data is actually stored.

[0045] The translation device driver also generates tape drive commands that are necessary to properly position a tape volume mounted on a tape drive to access a particular tape record. Prior to processing a tape drive access request to access a particular tape record, a tape volume mounted on a tape drive must be positioned to that particular tape record. Thus, because the virtual tape system operates in a manner that is similar to a physical tape drive, the virtual tape system must also be manipulated in order to position a virtual tape volume mounted on a particular virtual tape drive, to a particular tape record location. After the virtual tape volume is properly positioned, the particular record on the virtual tape volume can be accessed.

[0046] After receiving the disk drive request and translating the disk drive location into a virtual tape volume location, the translation device driver issues a command to position the virtual tape volume mounted on a virtual tape drive to the particular tape record location. The translation device driver then generates a tape drive command that is in a tape drive format to access the particular record within the particular virtual tape volume.

[0047] The virtual tape system generates a response to the access of the virtual tape volume. This response is in a tape drive format. The virtual tape system then transmits this response to the translation device driver. The translation device driver then translates the response back to a disk drive format. The translation device driver may include an indication in the response of the particular disk drive and block within the disk drive that was requested to be accessed.

[0048] Thus, the translation device driver converts requests and responses between a disk drive format and a tape drive format. In addition, the translation device driver converts between disk addresses and tape addresses so that the proper address is included in a request or a response. The translation device driver also generates any tape drive commands that are necessary to execute an access request, e.g. LOCATE commands.

[0049] In addition to the features described above, the present invention permits a virtual tape system that is designed to operate in append-only mode to operate in an update-in-place mode. The virtual tape system has been modified according to the present invention so that when data within the virtual tape system is modified, the remaining data in the system is not invalidated. Thus, the modified virtual tape system permits update-in-place modification to its data.

[0050] The translation device driver provides a user command processor and device attributes storage so that the translation device driver can also process control operation commands. The requests described above are read or write requests to read or write to a particular disk drive location. In addition to read and write requests, it may be necessary to execute other types of disk drive commands. A user may at some time wish to access a disk drive to execute commands other than reads or writes. These other commands are referred to herein as control operation commands. For example, these commands may include commands to format a disk drive or retrieve the disk drive's partition table.

[0051] The translation device driver only presents virtual disk images to disk applications such as a file system. A particular virtual disk image is created by configuring the translation device driver to represent the particular virtual disk image. A virtual disk image is realized within the translation device driver as a set of stored device attributes that represent the properties of the virtual disk image. The translation device driver stores virtual disk configuration information in device attributes storage maintained within the driver when the virtual disk image is created. These device attributes are then used to respond to control operation commands to access the virtual disk image.

[0052] FIG. 3 is a block diagram of a data processing system 300 that uses disk-based file system 302 to access a virtual tape system 304 through a translation device driver 306 in accordance with the present invention.

[0053] Translation device driver 306 receives read and write requests from disk-based file system 302. These read and write requests are in a disk-based format that is used when accessing a disk drive. Translation device driver 306 receives these requests, translates the requests into a tape-based format, and then forwards the tape-based requests to tape driver 308. Tape driver 308, then, forwards the requests to virtual tape system 304.

[0054] Virtual tape system 304 includes a plurality of different virtual tape drives (VTDs), such as VTD 310, VTD 312, and VTD 314. Each virtual tape drive is associated with one or more virtual tape volumes (VTVs). For example, VTD 310 is associated with VTV 316. VTD 312 is associated with VTV 318. And, VTD 314 is associated with VTV 320.

[0055] All of the virtual tape volumes are a part of a virtual tape buffer 322. According to an important feature of the present invention, virtual tape buffer 322 is implemented in a physical disk drive. Thus, when data is read from or written to a virtual tape volume within a virtual tape drive, that data is actually physically stored on a physical disk drive.

[0056] Virtual tape system 304 is associated with one or more physical tape drives such as real tape drive 324 and real tape drive 326. Data that is stored in a virtual tape volume may be further backed up by moving that data to a tape cartridge that is inserted into the VTV's associated physical tape drive. For example, virtual tape volume 316 is associated with tape cartridge 328. Data that is stored within VTV 316 may be moved to cartridge 328 that can be inserted into real tape drive 326. Virtual tape volumes 318 and 320 are associated with tape cartridge 330. Data that is stored within either VTV 318 or VTV 320 may be moved to cartridge 330 that can be inserted into real tape drive 324.

[0057] FIG. 4 depicts a high level flow chart that illustrates the overall process of the present invention that utilizes a disk-based device driver to access a virtual tape drive in accordance with the present invention. The process starts as depicted by block 400 and thereafter passes to block 402 which illustrates a process that is in the user space requesting disk file access of a logical disk location. This may be a request by the user process to read a logical disk location or a request to write to a logical disk location.

[0058] The process then passes to block 404 which depicts the file system receiving the request and translating the logical disk location to a particular virtual disk location. Next, block 406 illustrates a translation device driver receiving the request for the particular virtual disk location. Block 408, then, depicts the translation device driver translating the disk file request for the virtual disk location into a tape drive request for a particular tape location. The particular tape location is a particular tape record location in a particular virtual tape volume. This particular virtual tape volume is associated with a particular virtual tape drive. At this time, the virtual tape volume is logically mounted on its associated particular virtual tape drive.

[0059] Thereafter, block 412 illustrates the translation device driver accessing data in the virtual tape volume that is mounted on the virtual tape drive. The process then passes to block 414 which depicts the translation device driver receiving, from the virtual tape drive, a response to the access of the virtual tape volume. Next, block 416 illustrates the translation device driver translating the virtual tape drive's response from a tape format into a disk drive format. Block 418, then, depicts the translation device driver transmitting this response that is in the disk drive format to the file system. Thereafter, block 420 illustrates the file system transmitting a response to the disk file access to the user process. The process then terminates as depicted by block 422.

[0060] FIG. 5 is a block diagram of a first embodiment 500 in accordance with the present invention. The first embodiment is implemented within a computer system 500, such as the computer system depicted by FIG. 15. The present invention is implemented as a “user space” process according to the first embodiment. Computer system 500 executes an operating system that includes a kernel. The kernel is responsible for managing the lower level operations of computer system 500. For example, the kernel is responsible for managing memory accesses, files, and communications with hardware components such as peripherals.

[0061] The kernel is also responsible for communicating with software applications that are executing on top of the operating system. The kernel executes in “kernel space” while the software and user applications execute in “user space”. As depicted by FIG. 5, a user application 502, also called a process, is executing in user space 504. Translation device driver 505 is also executing in user space 504. File system 302 is located in kernel space 506. Pseudo device driver 508 and tape driver 308 are both executing in kernel space 506.

[0062] Requests that are transmitted and executed in user space 504 are expected in a particular format. Requests that are transmitted and executed in kernel space 506 are expected in a different particular format. Because translation device driver 505 is executing in user space 504 in the embodiment depicted by FIG. 5, pseudo device driver 508 is provided in kernel space 506 to repackage requests between user space 504 and kernel space 506.

[0063] Translation device driver 505 includes block translation logic 512, block translation map 514, a user command processor 520, and device attributes 522.

[0064] User command processor 520 is used to receive and process commands from a human operator. User command processor 520 is used to create a virtual disk image as an element of translation device driver 505. User command processor 520 also manipulates a defined virtual disk image using the information that is stored in device attributes 522.

[0065] Information describing the attributes of a virtual disk image is stored in device attributes 522 when a virtual disk image is created and configured. This information describes the configuration of a particular virtual disk image as an element of the translation device driver 505. This configuration data includes the volume serial number(s) of the formatted virtual tape volume(s) that comprise the backing storage for the virtual disk, the number of formatted records on each virtual tape volume, the virtual disk label, the virtual disk block size, the virtual disk partition table, and other attributes completing the virtual disk description.

[0066] Before a process or an application such as file system 302 can access a newly created virtual disk image, a human operator must format the complete set of virtual tape volumes assigned to this virtual disk image using techniques known in the art. Each virtual tape volume must be formatted as a series of consecutive fixed-length records. The length of each record must equal the block size defined for the virtual disk image. Formatting, which is performed only once when creating a virtual disk, establishes block-addressable record locations on the virtual tape volumes. The human operator must then use command processor 520 to ready the virtual disk for use by a process or application such as file system 302. For a particular virtual disk image, user command processor 520 will mount the corresponding virtual tape volume(s) on virtual tape drive(s) in the virtual tape system 304. Also for a particular virtual disk image, user command processor 520 will update block translation map 514 to denote the associations between the virtual disk, the virtual tape volume(s) comprising that virtual disk, and the virtual tape drives upon which those virtual tape volumes are mounted. Once these steps are completed, processes and applications such as file system 302 can access the virtual disk.

[0067] Processes and applications, such as file system 302, access and manipulate a virtual disk image exactly as if it were a physical disk. A process or the file system 302 needs to access a virtual disk image at times to perform functions other than reading and writing data to the virtual disk image. For example, a FORMAT command may be issued to format a virtual disk image. At other times, a process or the file system 302 needs to determine how much total storage a virtual disk image can provide. A process or the file system 302 may need to obtain the partition table of a virtual disk image. These types of commands are control operation commands that are not read/write commands. Translation device driver 505 processes control operation commands using the information stored in device attributes 522. The processing of read/write commands are described in more detail below.

[0068] User process 502 generates a request to read a logical disk file location, i.e. “filex”, and put the data that is read from that location into a buffer “buf” 510 within user process 502. This request is transmitted to file system 302 which then translates the logical disk file location, filex, to a virtual disk file location, e.g., “d1, i”. This virtual disk location indicates a virtual disk “d1” and a block “i” within that disk. A new request to read d1, i and put the results in buffer “buf” is then transmitted from file system 302 to pseudo device driver 508. This new request is in a kernel space format.

[0069] Pseudo device driver 508 then repackages the new request from a kernel space format into a message in a user space format to read d1,i and put the results in buffer “buf”. This user space message is then transmitted from pseudo device driver 508 to translation device driver 505.

[0070] Translation device driver 505 receives this message within block translation logic 512. The message includes the indication of virtual disk drive and block number as parameters.

[0071] Block translation logic 512 executes a translation function “f”. This translation function is a process that accesses a block translation map 514. Block translation map 514 is prestaged when virtual tape volumes are mounted on particular virtual tape drives for a particular virtual disk. Block translation map 514 maintains a map between virtual disk drives and virtual tape volumes. The association between virtual tape volume(s) that are used to represent a particular virtual disk drive is kept in block translation map 514 for each virtual disk drive.

[0072] When a particular virtual tape volume is mounted on a particular virtual tape drive, an association between that particular VTV and the particular VTD is established in block translation map 514. Therefore, when a particular virtual tape volume is identified, it is known which virtual tape drive is associated with that virtual tape volume.

[0073] Translation function “f” executes with the parameters that are passed to it. In this case the parameters are “d1,i”. Translation function “f” accesses block translation map 514 and device attributes 522 to determine which VTV, and thus which VTD, corresponds to virtual disk drive “d1”, and which block within that VTV corresponds to block “i”.

[0074] In the example depicted by FIG. 5, virtual tape drive 2 (VTD2) 312 corresponds to virtual disk drive d1, and block “k” within VTV2 318 corresponds to block “i” within disk drive d1. Block translation logic 512 then generates a tape drive LOCATE command which is transmitted to tape driver 308 which forwards the command to VTD2 312. This LOCATE command will cause VTD2 312 to position the virtual tape media VTV2 318 to block k. Block translation logic 512 then issues a tape drive READ command to read the data that is stored at the location where the virtual tape volume is positioned in VTD2 312, i.e. block k. This READ command includes a location “tbuf” where the data that is read from VTV2 318 is to be stored. The location “tbuf” is a buffer 516 within block translation logic 512.

[0075] Block translation logic 512 then returns to pseudo device driver 508 the data that is stored in tbuf 516 for virtual disk drive location “d1,i”. This data is in a user space 504 format and is transmitted to pseudo device driver 508. Pseudo device driver 508 repackages this data into a kernel space 506 format. This data that is now in a kernel space format is transmitted to file system 302. File system 302 then sends the data to user process 502 to be stored in buffer 510.

[0076] FIG. 6 depicts a high level flow chart that illustrates using a disk-based device driver to read data from a virtual tape volume in accordance with a first embodiment, depicted by FIG. 5, in accordance with the present invention. The process starts as depicted by block 600 and thereafter passes to block 602 which illustrates the user process issuing a disk file read command to read a particular logical disk location. The command indicates that the data that is read is to be stored in a buffer within the user process.

[0077] The process then passes to block 604 which depicts the file system receiving the request and translating the particular logical disk location to a virtual disk location. The virtual disk location is represented in the disk file read command as a particular disk drive and a particular block number within that disk drive. Next, block 606 illustrates the kernel pseudo device driver receiving, within the kernel space, the disk file read command and generating a message, in the user space format, for the translation device driver.

[0078] Thereafter, block 608 depicts the translation device driver receiving this message within the user space. The translation device driver then accesses a translation map to identify which virtual tape drive maps to that particular virtual disk drive. Block 610, then, depicts the translation device driver determining which virtual tape volume, and thus which virtual tape drive, includes a record that corresponds to the requested disk block.

[0079] The process passes to block 612 which illustrates the translation device driver issuing a tape drive LOCATE command which positions the virtual tape volume to the record in the volume that corresponds to the requested block location. Next, block 614 depicts the translation device driver issuing a tape drive READ command to read the record and store the data read from the record into a buffer within the translation device driver. Thereafter, block 616 illustrates a tape driver receiving the tape drive LOCATE and READ commands and then transmitting them to the virtual tape drive.

[0080] Then, block 618 depicts the virtual tape drive reading the record in the virtual tape volume and transmitting the data it reads to the tape driver. The tape driver then transmits this data to the translation device driver. Next, block 620 illustrates the translation device driver storing the data in the translation device driver's buffer. Thereafter, block 622 depicts the translation device driver returning the data to the pseudo device driver. The data returned contains the data read from the record in the virtual tape volume and a tag that indicates that the data is associated with the particular virtual disk drive and block.

[0081] Block 624, then, depicts the kernel pseudo device driver receiving, in the kernel space, the data returned from the translation device driver. The kernel pseudo device driver then generates a response in the disk format that includes the data and indicates the particular virtual disk drive and block. This disk drive response is then presented, in the kernel space, to the file system.

[0082] The process then passes to block 626 which illustrates the file system transmitting the response to the disk file access, including the data read from the virtual tape volume record that corresponds to the requested virtual disk drive block, to the user process. Thereafter, block 628 depicts the user process receiving the data in its buffer. The process then terminates as illustrated by block 630.

[0083] FIG. 7 is a block diagram of a second embodiment 700 in accordance with the present invention. The second embodiment is implemented within a computer system 700, such as the computer system depicted by FIG. 15. The present invention is implemented as a “kernel space” process according to the second embodiment. Computer system 700 executes an operating system that includes a kernel. The kernel is responsible for managing the lower level operations of computer system 700. For example, the kernel is responsible for managing memory accesses, files, and communications with hardware components such as peripherals. As depicted by FIG. 7, a user application 702, also called a process, is executing in user space 704. Translation device driver 713 is executing in kernel space 706. File system 302 and tape driver 308 are also located in kernel space 706.

[0084] Translation device driver 713 includes block translation logic 714, block translation map, 715, driver command processor 717, and device attributes 719.

[0085] User command processor 716 is used to receive and process commands from a human operator. Its purpose is identical to user command processor 520 as described in the embodiment depicted by FIG. 5. User command processor 716 is used to create a virtual disk image as an element of translation device driver 713. User command processor 716 also manipulates a defined virtual disk image using the information that is stored in device attributes 719.

[0086] Information describing the attributes of a virtual disk image is stored in device attributes 719 when a virtual disk image is created and configured. This information describes the configuration of a virtual disk image as an element of the translation device driver 713.

[0087] User command processor 716, which executes in user space 704, exchanges commands, data and status with driver command processor 717, which executes in kernel space 706. Driver command processor 717 updates block translation map 715 and device attributes 719 as directed by user command processor 716. Driver command processor 717 also returns data and status to user command processor 716 in response to requests from user command processor 716.

[0088] User process 702 generates a request to read a logical disk file location, i.e. “filex”, and put the data that is read from that location into a buffer “buf” 711 within user process 702. This request is transmitted to file system 302 which then translates the logical disk file location, filex, to a virtual disk file location, e.g., “d1, i”. This virtual disk location indicates a virtual disk “d1” and a block “i” within that disk. A new request to read d1, i and put the results in buffer “buf” is then transmitted from file system 302 to translation device driver 713. Translation device driver 713 receives this request within block translation logic 714. The request includes the virtual disk drive and block as parameters.

[0089] Block translation logic 714 executes a translation function “f”. This translation function is a process that accesses a block translation map 715. Block translation map 715 is prestaged when virtual tape volumes are mounted on particular virtual tape drive for a particular virtual disk. Block translation map 715 maintains a map between virtual disk drives and virtual tape volumes.

[0090] Translation function “f” executes with the parameters that are passed to it. In this case the parameters are “d1,i”. Translation function “f” accesses block translation map 715 and device attributes 719 to determine which VTV, and thus which VTD, corresponds to virtual disk drive “d1”, and which block within that VTV corresponds to block “i”.

[0091] In the example depicted by FIG. 7, virtual tape drive 2 (VTD2) 312 corresponds to virtual disk drive d1, and block “k” within VTV2 318 corresponds to block “i” within disk drive d1. Block translation logic 714 then generates a tape drive LOCATE command which is transmitted to tape driver 308 which forwards the command to VTD2 312. This LOCATE command will cause VTD2 312 to position the virtual tape media VTV2 318 to block k. Block translation logic 714 then issues a tape drive READ command to read the data that is stored at the location where the virtual tape volume is positioned in VTD2 312, i.e. block k.

[0092] Block translation logic 714 then receives the data back from tape driver 308 that was read from block k within VTV2 318. Translation device driver 713 then generates a response, in a disk drive format, that includes the data that was read from VTV2 318. This response is in the disk drive format expected by file system 302. This response is then transmitted to file system 302. File system 302 then sends the data to user process 702 to be stored in buffer 711.

[0093] FIG. 8 illustrates a high level flow chart that depicts using a disk-based device driver to read data from a virtual tape volume in accordance with a second embodiment, depicted by FIG. 7, in accordance with the present invention. The process starts as depicted by block 800 and thereafter passes to block 802 which illustrates the user process issuing a disk file read command to read a particular logical disk location. The command indicates that the data that is read is to be stored in a particular buffer within the user process.

[0094] The process then passes to block 804 which depicts the file system receiving the request and translating the particular logical disk location to a virtual disk location. The virtual disk location indicates a particular virtual disk drive and buffer. Then, block 808 depicts the translation device driver determining which virtual tape volume, and thus which virtual drive, includes a tape record that corresponds to the requested block in the particular virtual disk drive. Thereafter, block 810 illustrates the translation device driver issuing a tape drive LOCATE command which positions the virtual tape volume to the record that corresponds to the requested block location.

[0095] The process then passes to block 812 which depicts the translation device driver issuing a tape drive READ command to read the tape record and then store the data read from this record into a buffer within the translation device driver. Thereafter, block 814 illustrates the tape driver receiving the LOCATE and READ commands and then transmitting them to the virtual tape drive. Block 816, then, depicts the virtual tape drive reading the record in the virtual tape volume and transmitting the data read from the virtual tape drive to the tape driver. The tape driver then transmits the data to the translation device driver. Next, block 818 illustrates the translation device driver storing the data in a buffer within the translation device driver. The process then passes to block 820 which depicts the translation device driver presenting the data, read from the record in the virtual tape volume, in disk format to the file system. Thereafter, block 822 illustrates the file system transmitting the disk file access response, including the data read from the record that corresponds to the requested virtual disk drive block, to the user process. Thereafter, block 824 depicts the user process receiving the data in its buffer. The process then terminates as illustrated by block 826.

[0096] FIG. 9 depicts a high level flow chart that illustrates using a disk-based device driver to write data to a virtual tape volume in accordance with a first embodiment, depicted by FIG. 5, in accordance with the present invention. The process starts as depicted by block 900 and thereafter passes to block 902 which illustrates a user process issuing a disk file write command to write data from a user buffer to a particular logical disk location. Next, block 904 depicts the file system receiving the command and translating the particular logical disk location to a particular virtual disk location indicated by a particular virtual disk drive and block.

[0097] The process then passes to block 906 which illustrates the kernel pseudo device driver receiving, in the kernel space, the disk file write command. The disk file write command includes the data to be written. The kernel pseudo device driver generates a message for the translation device driver that is located in the user space.

[0098] Thereafter, block 910 illustrates the translation device driver determining which virtual tape volume, and thus which virtual tape drive, includes a record that corresponds to the virtual disk block to be written to. Block 912, then, depicts the translation device driver issuing a tape drive LOCATE command which positions that virtual tape volume to the record that corresponds to the virtual disk block to be written to. The process then passes to block 914 which illustrates the translation device driver issuing a tape drive WRITE command to write data to the record that corresponds to the virtual disk drive block. The command includes the data to be written to the virtual disk drive block.

[0099] Then, block 916 depicts the tape driver receiving the LOCATE and WRITE commands and then transmitting them to the virtual tape drive. Next, block 918 illustrates the virtual tape drive writing the data to the record in the virtual tape volume. The virtual tape drive transmits a response to the tape driver that the write is complete. The tape driver then transmits the response to the translation device driver.

[0100] Next, block 920 depicts the translation device driver returning a message to the pseudo device driver. The message includes the response from the virtual tape drive that the write is complete. Thereafter, block 922 illustrates the kernel pseudo device driver receiving, in the kernel space, the message and presenting it, in the kernel space, in a disk format to the file system. The process then passes to block 924 which depicts the file system transmitting the disk file access response that indicates that the write is complete. Next, block 926 illustrates the user process receiving the response to its WRITE command that the write is complete. The process then terminates as depicted by block 928.

[0101] FIG. 10 illustrates a high level flow chart that depicts using a disk-based file system to write data to a virtual tape volume in accordance with a second embodiment, depicted by FIG. 7, in accordance with the present invention. The process starts as depicted by block 1000 and thereafter passes to block 1002 which illustrates a user process issuing a disk file write command to write data from a user buffer to a particular logical disk location. Next, block 1004 depicts the file system receiving the command and translating the particular logical disk location to a particular virtual disk location indicated by a particular virtual disk drive and block.

[0102] Thereafter, block 1010 illustrates the translation device driver determining which virtual tape volume, and thus which virtual tape drive, includes a record that corresponds to the virtual disk block to be written to. Block 1012, then, depicts the translation device driver issuing a tape drive LOCATE command which positions that virtual tape volume to the record that corresponds to the virtual disk block to be written to. The process then passes to block 1014 which illustrates the translation device driver issuing a tape drive WRITE command to write data to the record that corresponds to the virtual disk drive block. The command includes the data to be written to the virtual disk drive block.

[0103] Then, block 1016 depicts the tape driver receiving the LOCATE and WRITE commands and then transmitting them to the virtual tape drive. Next, block 1018 illustrates the virtual tape drive writing the data to the record in the virtual tape volume. The virtual tape drive transmits a response to the tape driver that the write is complete. The tape driver then transmits the response to the translation device driver.

[0104] Next, block 1020 depicts the translation device driver receiving the response and putting the response in a disk drive format. The disk drive format response is then transmitted to the file system. The process then passes to block 1024 which depicts the file system transmitting the disk file access response that indicates that the write is complete. Next, block 1026 illustrates the user process receiving the response to its WRITE command that the write is complete. The process then terminates as depicted by block 1028.

[0105] FIG. 11 illustrates a high level flow chart that depicts a tape drive operating in append-only mode for modification of data stored on the tape drive in accordance with the prior art. The process starts as depicted by block 1100 and thereafter passes to block 1102 which illustrates a virtual tape drive receiving a WRITE command to write to a particular record in the virtual tape volume mounted on the virtual tape drive. Next, block 1104 depicts the virtual tape drive writing data to the record. The process then passes to block 1106 which illustrates the virtual tape drive writing an end-of-data mark at the end of the record where the data was stored. The end-of-data mark invalidates all data that is stored in the virtual tape volume after the end-of-data mark. Block 1108, then, depicts the virtual tape drive completing the write command and returning a response that the write was completed. The process then terminates as illustrated by block 1110.

[0106] FIG. 12 depicts a high level flow chart that illustrates a tape drive that permits update-in-place modification of data stored on the tape drive in accordance with the present invention. The process starts as depicted by block 1200 and thereafter passes to block 1202 which illustrates a virtual tape drive receiving a WRITE command to write to a particular record in the virtual tape volume in the virtual tape drive. Next, block 1204 depicts the virtual tape drive writing data to the record. The process then passes to block 1206 which illustrates the virtual tape drive not writing an end-of-data mark at the end of the record where the data was stored. According to the present invention, no end-of-data mark is written when data is written to a virtual tape drive. Block 1208, then, depicts the virtual tape drive completing the write command and returning a response that the write was completed. The process then terminates as illustrated by block 1210.

[0107] FIG. 13 illustrates a high level flow chart that depicts storing device attributes within a translation device driver in accordance with the present invention. The process starts as depicted by block 1300 and thereafter passes to block 1302 which illustrates creating a virtual disk image. This virtual disk image is created when the translation device driver is configured to represent the particular virtual disk image. Next, block 1304 depicts accessing a user command processor in the translation device driver to store properties of the virtual disk image in the device attributes storage in the translation device driver. The process then terminates as illustrated by block 1306.

[0108] FIG. 14 depicts a high level flow chart that illustrates receiving commands and processing control operation commands using device attributes stored in a translation device driver in accordance with the present invention. The process starts as depicted by block 1400 and thereafter passes to block 1402 which illustrates receiving a command within the translation device driver. Next, block 1404 depicts a determination of whether or not the command is a control operation command or a command to either read or write. If a determination is made that the command is a read/write command, the process passes to block 1406 which illustrates the translation device driver processing the read/write command as described above with reference to FIGS. 3-12. The process then terminates as depicted by block 1412.

[0109] Referring again to block 1404, if a determination is made that the command is a control operation command, the process passes to block 1408 which depicts the translation device driver accessing device attributes to determine how to process the control operation command. Next, block 1410 illustrates the translation device driver processing the control operation command using the device attributes included within the translation device driver. The process then terminates as depicted by block 1412.

[0110] FIG. 15 is a block diagram of a data processing system that may include the present invention in accordance with the present invention. Data processing system 1500 may be a symmetric multiprocessor (SMP) system including a plurality of processors 1502 and 1504 connected to system bus 1506. Alternatively, a single processor system may be employed. Also connected to system bus 1506 is memory controller/cache 1508, which provides an interface to local memory 1509. I/O bus bridge 1510 is connected to system bus 1506 and provides an interface to I/O bus 1512. Memory controller/cache 1508 and I/O bus bridge 1510 may be integrated as depicted.

[0111] Peripheral component interconnect (PCI) bus bridge 1514 connected to I/O bus 1512 provides an interface to PCI local bus 1516. A number of modems may be connected to PCI bus 1516. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to other network computers may be provided through modem 1518 and network adapter 1520 connected to PCI local bus 1516 through add-in boards.

[0112] Additional PCI bus bridges 1522 and 1524 provide interfaces for additional PCI buses 1526 and 1528, from which additional modems or network adapters may be supported. In this manner, data processing system 1500 allows connections to multiple network computers. A memory-mapped graphics adapter 1530 and hard disk 1532 may also be connected to I/O bus 1512 as depicted, either directly or indirectly.

[0113] Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 15 may vary and could indeed be a mainframe architecture rather than the depicted architecture. In addition, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.

[0114] It is important to note that the present invention has been described in the context of a fully functioning data processing system. Those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.

[0115] The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.