US20070016825A1 - Resource allocation aware queuing of requests for media resources - Google Patents
Resource allocation aware queuing of requests for media resources Download PDFInfo
- Publication number
- US20070016825A1 US20070016825A1 US11/524,494 US52449406A US2007016825A1 US 20070016825 A1 US20070016825 A1 US 20070016825A1 US 52449406 A US52449406 A US 52449406A US 2007016825 A1 US2007016825 A1 US 2007016825A1
- Authority
- US
- United States
- Prior art keywords
- media resource
- queue
- request
- resource request
- media
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
- G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
Definitions
- the present invention relates generally to removable storage media. More specifically, resource allocation aware queuing of requests for media resources is disclosed.
- Fully or partially automated media libraries are available to store and manipulate removable storage media, such as tapes used to store computer data for backup or archive purposes.
- a typical library may be equipped with a robotic or other mechanism for manipulating the media stored therein, such as by inserting a selected volume or unit of the media (e.g., a particular tape) into a read/write device associated with the unit, e.g., a tape drive configured to write data to and/or read data from the media.
- a selected volume or unit of the media e.g., a particular tape
- a read/write device associated with the unit
- one or more backup applications may be used to store data from one or more computers or other devices connected to the network (sometimes referred to herein as network “nodes” or “hosts”) on storage media associated with a library.
- a media management application may be provided to facilitate the tracking of removable storage media resources and to coordinate the servicing of requests for removable media storage resources, such as a request by a backup application that a particular volume of media be mounted on a particular drive for a backup (or restore) operation.
- requests for removable media storage resources such as a request by a backup application that a particular volume of media be mounted on a particular drive for a backup (or restore) operation.
- multiple competing demands for the same resource may be received by the media management application at the same time. For example a first request that a first volume be mounted on a designated media storage drive may be received and a second request that a second volume be mounted on the same drive may received while the first request is still pending. In such situations, the media management application must determine which request to service first.
- One typical approach is to assign different priorities to different hosts and/or data sets having different levels of importance to network stakeholders (e.g., a commercial or other enterprise) and/or having different requirements for backup and/or restoration using removable storage media and associated storage devices.
- network stakeholders e.g., a commercial or other enterprise
- priorities may not be sufficient to ensure that the most important requests are serviced in a timely manner. For example, competing requests assigned the same priority may be received at the same time. Also, a storage device may be busy with a lower priority request that takes a long time to complete at a time when an urgent, higher priority request for the same device is received.
- FIG. 1 is a block diagram illustrating one exemplary embodiment of a network environment and an associated media management system.
- FIG. 2 is a flow chart illustrating a process used in some embodiments to provide resource allocation aware queuing of requests for media resources.
- FIG. 3 is a flow chart illustrating a process used in some embodiments to configure one or more queues, as in step 202 of FIG. 2 .
- FIG. 4 illustrates a set of queues defined via the process shown in FIG. 3 .
- FIG. 5 is a flowchart illustrating a process used in some embodiments to receive requests and assign them to a queue, as in step 204 of FIG. 2 .
- FIG. 6 is a flow chart illustrating a process used in some embodiments to service requests in accordance with their assigned queue and priority, as in step 206 of FIG. 2 .
- the invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links.
- these implementations, or any other form that the invention may take, may be referred to as techniques.
- the order of the steps of disclosed processes may be altered within the scope of the invention.
- a media resource request queue is defined.
- One or more removable storage media resources such as a read/write device, are associated with the queue.
- a request category is associated with the queue. Subsequently, removable storage media resource requests that are associated with the request category are placed in the queue and serviced by a resource associated with the queue.
- FIG. 1 is a block diagram illustrating one exemplary embodiment of a network environment and an associated media management system.
- the system 100 comprises a network 102 , which may be a local area network (LAN) or any type of private or public network.
- the system 100 further comprises servers A, B, C, and D, identified by reference numerals 104 , 106 , 108 , and 110 , respectively, in FIG. 1 , connected to network 102 .
- a first backup application such as the NetWorker backup application available commercially from the Legato Software Division of EMC Corporation, is installed on server A ( 104 ), and a second backup application is installed on server B ( 106 ).
- the first and second backup applications may be the same or different products.
- the data on server C ( 108 ) is backed up by both the first backup application installed on server A ( 104 ) and the second backup application installed on server B ( 106 ), as is indicated in FIG. 1 by the letters “A” and “B” in parentheses below the letter “C”.
- Such a configuration may be used, e.g., to provide two independent backups for particularly critical data.
- Server D ( 110 ) is backed up by the first backup application installed on server A ( 104 ).
- Server A may likewise comprise a body of data that is backed up by operation of the first backup application installed on server A
- server B may comprise a body of data that is backed up by operation of the second backup application installed on server B.
- SCSI library 112 is a library configured to be controlled directly by a library host 114 via a small computer systems interface (SCSI) connection.
- Library host 114 is connected to SCSI library 112 and to network 102 .
- ACSLS library 116 is an automated cartridge system library software-controlled library of the type available commercially from Storage Technology Corporation (StorageTek) of Louisville, Colo.
- An ACSLS-type library such as library 116 is controlled using a software controller provided for that purpose, as opposed to being controlled directly by the library host.
- Library host 118 is connected to and configured to control ACSLS library 116 .
- Library host 118 also is connected to network 102 .
- SCSI library 112 has associated with and connected to it tape drives 120 , 122 , and 124 .
- Tape drive 120 is connected to a network attached storage (NAS) device 126 .
- the data on NAS 126 is backed up by operation of the second backup application installed on server B.
- NAS 126 also has a connection to network 102 .
- ACSLS library 116 has associated with and connected to it tape drives 128 , 130 , 132 , and 134 .
- Tape drive 128 is connected to server A.
- Tape drives 130 , 132 , and 134 are connected to servers C ( 108 ) and D ( 110 ) via a storage area network (SAN) 136 .
- SAN 136 makes it possible for each of servers C and D to read from or write to any one of the SAN-connected tape drives 130 , 132 , and 134 .
- a media management application is installed on a media manager 138 to coordinate operations between the first backup application running on server A and the second backup application running on server B, such as by receiving and arbitrating between potentially competing requests for resources associated with libraries 112 and 116 , as well as executed such requests.
- the media manager may receive requests from the backup applications that a particular tape residing in one of the libraries be inserted into a tape drive associated with that library.
- the media management application may provide other functionality, such as keeping track of tapes stored in the libraries and elsewhere.
- the media manager 138 has a connection to the network 102 , which it uses to communicate with other nodes connected to network 102 as described more fully below.
- the media manager 138 may comprise a server connected to network 102 .
- the techniques described herein may be used to allocate or dedicate a subset of the available removable storage media resources to a queue established to service requests associated with the critical system and/or data. Absent such an allocation, a critical request may not be serviced in an adequately timely manner.
- NAS 126 comprised legal department files stored on server A ( 104 ), source code stored on server B ( 106 ), a mission critical database (e.g., a sales transaction and order status database) stored on server C ( 108 ), accounting data stored on server D ( 110 ), and user files stored on NAS 126 .
- a mission critical database e.g., a sales transaction and order status database
- server D ( 110 ) If due to regulatory or other legal requirements a large number of files, or a great deal of accounting data of various classes residing on server D ( 110 ) were required to be backed up onto different volumes of storage media, absent an allocation of media resources the backup application running on server A ( 104 ) might request that three different tapes be mounted on tape drives 130 , 132 , and 134 to back up accounting data on server D ( 110 ). If while these three backup operations were being performed the need arose to restore mission critical data to server C ( 108 ), no tape drive to which server C has a connection would be available to service the request.
- a queue may be defined for the purpose of servicing requests with respect to the database stored on server C.
- One or more of the tape drives on SAN 136 may be allocated to this queue, reserving the device(s) so allocated for the servicing of requests associated with server C.
- FIG. 2 is a flow chart illustrating a process used in some embodiments to provide resource allocation aware queuing of requests for media resources.
- one or more queues are configured.
- Step 202 may comprise defining one or more queues, assigning one or more storage devices with each queue, defining one or more request categories (e.g., a category for requests associated with the database on server C), and/or assigning one or more request categories to each queue.
- request categories e.g., a category for requests associated with the database on server C
- step 204 storage media resource requests, e.g., a request to mount a specified volume of storage media on designated device, are received (e.g., by a media management application) and assigned to an appropriate place in an appropriate queue. Step 204 is repeated as each request is received.
- requests in the queue(s) are serviced in accordance with their associated queue and priority. For example, a request that based on its assigned priority, time of receipt, etc. is the request next in line to be serviced in a queue associated with a drive that just became available (e.g., because a backup, restore, or other operation for which the device previously was being used was completed) may in an iteration of step 206 be serviced by mounting the volume indicated in the request on the available drive. Step 206 is repeated as each request is serviced.
- FIG. 3 is a flow chart illustrating a process used in some embodiments to configure one or more queues, as in step 202 of FIG. 2 .
- a data zone may comprise a set of hosts and associated data served by a particular backup application program.
- a first data zone may be defined for the hosts associated with a first backup application running on server A (i.e., servers A, C, and D) and a second data zone may be defined for the hosts associated with a second backup application running on server B (i.e., servers B and C and NAS 126 ).
- a data zone administrator may be designated and given the access required to configure queues with respect to his/her particular data zone, as described more fully below.
- one or more queues are defined. Defining a queue may comprise receiving an indication from a user that a new queue should be set up and receiving from the user (or assigning) a name or other identifier for the queue.
- one or more storage devices e.g., tape drives
- Step 306 may comprise receiving from a user via a user interface an indication that a designated tape drive should be associated with a particular queue.
- each device e.g., drive
- each queue is associated with one or more data zones.
- Step 308 may comprise giving a data zone administrator the access required to assign request categories to a queue, as described more fully below.
- one or more request categories are defined.
- the data zone administrator defines the request categories for his/her data zone. For example, in the case of a data zone associated with a backup application that associates related resources together in pools (e.g., related volumes of removable storage media), such as the NetWorker application described above, each pool may be associated with a request category.
- request categories may be defined, such as through a user interface, by defining a request category for a body of related data (e.g., accounting data, source code, user files, legal department files, etc.) and/or by defining a category by reference to a particular host (client), e.g., requests associated with server A in FIG. 1 .
- client e.g., requests associated with server A in FIG. 1 .
- each request category is associated with a queue.
- FIG. 4 illustrates a set of queues defined via the process shown in FIG. 3 .
- the set of queues 400 comprises five queues 402 , 404 , 406 , 408 , and 410 , also identified in FIG. 4 as Q 1 -Q 5 .
- the queues 400 are set up as shown for purposes of illustration and use the network environment 100 as shown in FIG. 1 by way of example.
- queues 406 , 408 , and 410 have been assigned to a data zone A and queues 402 , 404 , and 406 have been assigned to a data zone B.
- data zone A corresponds to the clients and storage nodes associated with the first backup application running on server A ( 104 ) of FIG.
- Each of the queues 400 has one or more storage devices allocated to it.
- device 120 is assigned queue Q 1 ( 402 )
- devices 122 and 124 are assigned to queue Q 2 ( 404 )
- devices 130 and 132 are assigned to queue Q 3 ( 406 )
- device 128 is assigned to queue Q 4 ( 408 )
- device 134 is assigned to queue Q 5 ( 410 ).
- Each queue is shown in FIG. 4 as having a single request category associated with it. However, in other embodiments more than one request category may be assigned to a queue.
- the request categories are based on the nature of the data that the backup applications are configured to backup/restore on each network client. For example, queue Q 1 ( 402 ) has assigned to it a request category named “user files”, which corresponds to the data backed up on the NAS 126 . Queue Q 2 ( 404 ) has assigned to it a request category named “source code”, which corresponds to the data backed up on server B.
- Queue Q 3 ( 406 ) has assigned to it a request category named “database”, which corresponds to the data backed up on server C (by both the first and second backup applications, i.e., in both data zones A and B).
- Queue Q 4 ( 408 ) has assigned to it a request category named “legal”, which corresponds to the data backed up on server A.
- queue Q 5 ( 410 ) has assigned to it a request category named “accounting”, which corresponds to the data backed up on server D.
- the queues Q 3 ( 406 ) and Q 5 ( 410 ) operate to allocate two of the three tape drives on SAN 136 (i.e., drives 130 and 132 ) to supporting requests associated with the database stored on server C ( 108 ) and the third drive on SAN 136 (i.e., drive 134 ) to supporting requests associated with the accounting files associated with server D ( 110 ).
- the resources on SAN 136 can be allocated in the way deemed most appropriate by the responsible network administrators, ensuring that the resources are used and/or available as required to support the data management (e.g., backup and restore) of the enterprise or other stakeholder(s) associated with the network.
- Each of the queues Q 1 -Q 5 has associated with it a pending request area, identified in FIG. 4 as areas 412 , 414 , 416 , 418 , and 420 , respectively. These areas are used as described more fully below to track pending requests associated with each queue.
- the queues themselves may be implemented in any number of ways known to those of ordinary skill in the art.
- each may comprise a data structure for storing pending requests and related data (e.g., priority, place in line, order or time in which received, etc.) and logic for receiving requests, determining their relative order within the queue, and selecting/identifying from among the pending request the next request to be serviced when a resource (e.g., drive) associated with the queue becomes available.
- a resource e.g., drive
- FIG. 5 is a flowchart illustrating a process used in some embodiments to receive requests and assign them to a queue, as in step 204 of FIG. 2 .
- a request for a removable storage media resource is received.
- the request may comprise, for example, a request that a particular volume of storage media (e.g., a specified tape) be mounted on a particular device (e.g., tape drive).
- the request is associated with a request category and a data zone. In some embodiments, the request may indicate the request category and/or data zone to which it relates.
- the request may comprise other information that may be used to associate the request with a request category and/or data zone, such as information identifying a pool, a client (host) system, or the data or data type to which the request relates, or indicating the backup or other application that generated the request.
- the request is assigned to a default queue for the data zone to which the request relates.
- the priority level of the request is determined. In some embodiments, step 506 may comprise receiving with the request an indication of the priority of the request.
- the priority may be determined at least in part by the type of operation associated with the request (e.g., a request associated with a restore operation may have higher priority than a request associated with a backup operation). In some embodiments, the priority may be determined at least in part based on the data and/or host to which the request relates.
- the request is place in the appropriate place in line in the appropriate queue. Step 508 may comprise placing the request in the queue that corresponds to the request category and data zone associated with the request, as determined in step 504 . Step 508 may comprise placing the request in the queue in a place determined at least in part by the priority determined in step 506 .
- a request may be placed in the queue in a position ahead of pending requests having a lower priority and behind pending requests having higher priority.
- requests of the same priority are handled on a first-in-first-out (FIFO) basis.
- FIFO first-in-first-out
- a user may alter the position of the request within the queue.
- a user interface may be provided to facilitate such altering of the order within a queue, such as by allowing a user to click on and drag a request from a current position in the queue to a new position.
- FIG. 6 is a flow chart illustrating a process used in some embodiments to service requests in accordance with their assigned queue and priority, as in step 206 of FIG. 2 .
- an indication is received that a resource associated with a queue is available.
- Such an indication may comprise, e.g., an indication from the backup application that a previously serviced request is complete.
- the indication may comprise an indication received from the library that a tape dismount operation with respect to the drive in question has been completed.
- the next request in line in the queue is identified from among the requests pending in the queue.
- the requests are stored in the queue in the order in which they are to be serviced, based on the nature of the request and/or other priority information, as described above.
- step 604 comprises reading from the first (i.e., next to be serviced) position in the queue information about the next request due to be serviced.
- the request identified in step 604 is serviced, e.g., by causing a tape specified in the request to be mounted on a drive specified in the request (and/or a drive associated with the queue, if none is specified in the request).
- Requests in a default queue may be handled similarly to requests in queues to which resources have been allocated, except that the resources (e.g., drives) available to service such requests are those to which the host associated with each respective request has a connection and that are not allocated to another queue.
- resources e.g., drives
- removable media storage resources e.g., tape drives
- removable media storage resources may be allocated to one or more queues, dedicating them to servicing requests associated with the respective queue to which each device is assigned. This provides network administrators with the ability to ensure that resources are used in an optimal manner and that resources are available in an adequately timely manner to service mission critical requests.
Abstract
Resource allocation aware processing of requests for media resources is disclosed. A queue is defined. A media resource is allocated to the queue. A media resource request is associated with the queue.
Description
- This application is a continuation of co-pending U.S. patent application Ser. No. 10/737,170, entitled RESOURCE ALLOCATION AWARE QUEUING OF REQUESTS FOR MEDIA RESOURCES filed Dec. 16, 2003, which is incorporated herein by reference for all purposes, and which claims priority to U.S. Provisional Application No. 60/434,471, entitled AUTOMATED MEDIA MANAGEMENT filed Dec. 18, 2002, which is incorporated herein by reference for all purposes.
- The present invention relates generally to removable storage media. More specifically, resource allocation aware queuing of requests for media resources is disclosed.
- Fully or partially automated media libraries, sometimes referred to as “libraries” or “robots”, are available to store and manipulate removable storage media, such as tapes used to store computer data for backup or archive purposes. A typical library may be equipped with a robotic or other mechanism for manipulating the media stored therein, such as by inserting a selected volume or unit of the media (e.g., a particular tape) into a read/write device associated with the unit, e.g., a tape drive configured to write data to and/or read data from the media. In the computer network environment, for example, one or more backup applications may be used to store data from one or more computers or other devices connected to the network (sometimes referred to herein as network “nodes” or “hosts”) on storage media associated with a library.
- A media management application may be provided to facilitate the tracking of removable storage media resources and to coordinate the servicing of requests for removable media storage resources, such as a request by a backup application that a particular volume of media be mounted on a particular drive for a backup (or restore) operation. In some network environments, multiple competing demands for the same resource may be received by the media management application at the same time. For example a first request that a first volume be mounted on a designated media storage drive may be received and a second request that a second volume be mounted on the same drive may received while the first request is still pending. In such situations, the media management application must determine which request to service first.
- One typical approach is to assign different priorities to different hosts and/or data sets having different levels of importance to network stakeholders (e.g., a commercial or other enterprise) and/or having different requirements for backup and/or restoration using removable storage media and associated storage devices. However, such a use of priorities may not be sufficient to ensure that the most important requests are serviced in a timely manner. For example, competing requests assigned the same priority may be received at the same time. Also, a storage device may be busy with a lower priority request that takes a long time to complete at a time when an urgent, higher priority request for the same device is received.
- Therefore, there is a need for a way to ensure that removable storage media resources (e.g., drives) are utilized in a way that ensures that the varying removable storage media resource requirements of different hosts and/or data sets are met.
- Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
-
FIG. 1 is a block diagram illustrating one exemplary embodiment of a network environment and an associated media management system. -
FIG. 2 is a flow chart illustrating a process used in some embodiments to provide resource allocation aware queuing of requests for media resources. -
FIG. 3 is a flow chart illustrating a process used in some embodiments to configure one or more queues, as instep 202 ofFIG. 2 . -
FIG. 4 illustrates a set of queues defined via the process shown inFIG. 3 . -
FIG. 5 is a flowchart illustrating a process used in some embodiments to receive requests and assign them to a queue, as instep 204 ofFIG. 2 . -
FIG. 6 is a flow chart illustrating a process used in some embodiments to service requests in accordance with their assigned queue and priority, as instep 206 ofFIG. 2 . - The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
- A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
- Resource allocation aware queuing of requests for media resources is disclosed. A media resource request queue is defined. One or more removable storage media resources, such as a read/write device, are associated with the queue. A request category is associated with the queue. Subsequently, removable storage media resource requests that are associated with the request category are placed in the queue and serviced by a resource associated with the queue.
-
FIG. 1 is a block diagram illustrating one exemplary embodiment of a network environment and an associated media management system. Thesystem 100 comprises anetwork 102, which may be a local area network (LAN) or any type of private or public network. Thesystem 100 further comprises servers A, B, C, and D, identified byreference numerals FIG. 1 , connected tonetwork 102. In the example shown inFIG. 1 , a first backup application, such as the NetWorker backup application available commercially from the Legato Software Division of EMC Corporation, is installed on server A (104), and a second backup application is installed on server B (106). The first and second backup applications may be the same or different products. The data on server C (108) is backed up by both the first backup application installed on server A (104) and the second backup application installed on server B (106), as is indicated inFIG. 1 by the letters “A” and “B” in parentheses below the letter “C”. Such a configuration may be used, e.g., to provide two independent backups for particularly critical data. Server D (110) is backed up by the first backup application installed on server A (104). Server A may likewise comprise a body of data that is backed up by operation of the first backup application installed on server A, and server B may comprise a body of data that is backed up by operation of the second backup application installed on server B. The storage media used by the first and second backup applications installed on servers A and B, respectively, reside in two storage media libraries of different types. SCSIlibrary 112 is a library configured to be controlled directly by alibrary host 114 via a small computer systems interface (SCSI) connection.Library host 114 is connected to SCSIlibrary 112 and tonetwork 102. ACSLSlibrary 116 is an automated cartridge system library software-controlled library of the type available commercially from Storage Technology Corporation (StorageTek) of Louisville, Colo. An ACSLS-type library such aslibrary 116 is controlled using a software controller provided for that purpose, as opposed to being controlled directly by the library host.Library host 118 is connected to and configured to control ACSLSlibrary 116.Library host 118 also is connected tonetwork 102. While examples of a SCSI and ACSLS type library are shown inFIG. 1 , any number of combination of types of libraries may be used, including without limitation IBM 3494, ADIC AML, and/or any other type of library. SCSIlibrary 112 has associated with and connected to ittape drives Tape drive 120 is connected to a network attached storage (NAS)device 126. The data on NAS 126 is backed up by operation of the second backup application installed on server B. NAS 126 also has a connection tonetwork 102. ACSLSlibrary 116 has associated with and connected to ittape drives Tape drive 128 is connected to serverA. Tape drives tape drives - A media management application is installed on a
media manager 138 to coordinate operations between the first backup application running on server A and the second backup application running on server B, such as by receiving and arbitrating between potentially competing requests for resources associated withlibraries media manager 138 has a connection to thenetwork 102, which it uses to communicate with other nodes connected to network 102 as described more fully below. Themedia manager 138 may comprise a server connected tonetwork 102. - To ensure the availability of removable storage media resources (e.g., devices, such as tape drives) to serve critical requests, such as to restore a mission critical system or particularly critical data, the techniques described herein may be used to allocate or dedicate a subset of the available removable storage media resources to a queue established to service requests associated with the critical system and/or data. Absent such an allocation, a critical request may not be serviced in an adequately timely manner. Consider an example in which the data requiring backup in the
network environment 100 ofFIG. 1 comprised legal department files stored on server A (104), source code stored on server B (106), a mission critical database (e.g., a sales transaction and order status database) stored on server C (108), accounting data stored on server D (110), and user files stored onNAS 126. - If due to regulatory or other legal requirements a large number of files, or a great deal of accounting data of various classes residing on server D (110) were required to be backed up onto different volumes of storage media, absent an allocation of media resources the backup application running on server A (104) might request that three different tapes be mounted on tape drives 130, 132, and 134 to back up accounting data on server D (110). If while these three backup operations were being performed the need arose to restore mission critical data to server C (108), no tape drive to which server C has a connection would be available to service the request. Under such circumstances, even if the media manager were to assign the highest priority to the request and/or otherwise ensure that the request related to restoring server C would be the next one serviced by the first tape drive to become available on
SAN 136, an unacceptable amount of time might elapse before such a resource became available. - To avoid the situation described above and similar potential problems, resource allocation aware queuing of requests for media resources is disclosed. For example, in the case of the
network environment 100 ofFIG. 1 , a queue may be defined for the purpose of servicing requests with respect to the database stored on server C. One or more of the tape drives onSAN 136 may be allocated to this queue, reserving the device(s) so allocated for the servicing of requests associated with server C. Using this approach, there is no risk that requests associated with server D, or any other host that may be on theSAN 136, may block the servicing of critical requests associated with server C. -
FIG. 2 is a flow chart illustrating a process used in some embodiments to provide resource allocation aware queuing of requests for media resources. Instep 202, one or more queues are configured. Step 202 may comprise defining one or more queues, assigning one or more storage devices with each queue, defining one or more request categories (e.g., a category for requests associated with the database on server C), and/or assigning one or more request categories to each queue. Instep 204, storage media resource requests, e.g., a request to mount a specified volume of storage media on designated device, are received (e.g., by a media management application) and assigned to an appropriate place in an appropriate queue. Step 204 is repeated as each request is received. Instep 206, requests in the queue(s) are serviced in accordance with their associated queue and priority. For example, a request that based on its assigned priority, time of receipt, etc. is the request next in line to be serviced in a queue associated with a drive that just became available (e.g., because a backup, restore, or other operation for which the device previously was being used was completed) may in an iteration ofstep 206 be serviced by mounting the volume indicated in the request on the available drive. Step 206 is repeated as each request is serviced. -
FIG. 3 is a flow chart illustrating a process used in some embodiments to configure one or more queues, as instep 202 ofFIG. 2 . Instep 302, one or more data zones are defined. A data zone may comprise a set of hosts and associated data served by a particular backup application program. For example, in thenetwork environment 100 ofFIG. 1 , a first data zone may be defined for the hosts associated with a first backup application running on server A (i.e., servers A, C, and D) and a second data zone may be defined for the hosts associated with a second backup application running on server B (i.e., servers B and C and NAS 126). In some embodiments, a data zone administrator may be designated and given the access required to configure queues with respect to his/her particular data zone, as described more fully below. Instep 304, one or more queues are defined. Defining a queue may comprise receiving an indication from a user that a new queue should be set up and receiving from the user (or assigning) a name or other identifier for the queue. Instep 306, one or more storage devices (e.g., tape drives) are associated with each queue. Step 306 may comprise receiving from a user via a user interface an indication that a designated tape drive should be associated with a particular queue. In some embodiments, each device (e.g., drive) may be assigned to only one queue. Devices not assigned to any queue are in some embodiments assigned by default to a default queue used to service requests that are not associated with any other queue. Instep 308, each queue is associated with one or more data zones. Step 308 may comprise giving a data zone administrator the access required to assign request categories to a queue, as described more fully below. Instep 310, one or more request categories are defined. In some embodiments, the data zone administrator defines the request categories for his/her data zone. For example, in the case of a data zone associated with a backup application that associates related resources together in pools (e.g., related volumes of removable storage media), such as the NetWorker application described above, each pool may be associated with a request category. Likewise, request categories may be defined, such as through a user interface, by defining a request category for a body of related data (e.g., accounting data, source code, user files, legal department files, etc.) and/or by defining a category by reference to a particular host (client), e.g., requests associated with server A inFIG. 1 . Instep 312, each request category is associated with a queue. -
FIG. 4 illustrates a set of queues defined via the process shown inFIG. 3 . The set ofqueues 400 comprises fivequeues FIG. 4 as Q1-Q5. Thequeues 400 are set up as shown for purposes of illustration and use thenetwork environment 100 as shown inFIG. 1 by way of example. In the example shown,queues queues FIG. 1 and data zone B corresponds to the clients and storage nodes associated with the second backup application running on server B (106) ofFIG. 1 . Each of thequeues 400 has one or more storage devices allocated to it. In this example,device 120 is assigned queue Q1 (402),devices devices device 128 is assigned to queue Q4 (408), anddevice 134 is assigned to queue Q5 (410). - Each queue is shown in
FIG. 4 as having a single request category associated with it. However, in other embodiments more than one request category may be assigned to a queue. In the example shown, the request categories are based on the nature of the data that the backup applications are configured to backup/restore on each network client. For example, queue Q1 (402) has assigned to it a request category named “user files”, which corresponds to the data backed up on theNAS 126. Queue Q2 (404) has assigned to it a request category named “source code”, which corresponds to the data backed up on server B. Queue Q3 (406) has assigned to it a request category named “database”, which corresponds to the data backed up on server C (by both the first and second backup applications, i.e., in both data zones A and B). Queue Q4 (408) has assigned to it a request category named “legal”, which corresponds to the data backed up on server A. Finally, queue Q5 (410) has assigned to it a request category named “accounting”, which corresponds to the data backed up on server D. - In the example shown in
FIG. 4 , one can see fromFIG. 1 that the queues Q3 (406) and Q5 (410) operate to allocate two of the three tape drives on SAN 136 (i.e., drives 130 and 132) to supporting requests associated with the database stored on server C (108) and the third drive on SAN 136 (i.e., drive 134) to supporting requests associated with the accounting files associated with server D (110). In this way, the resources onSAN 136 can be allocated in the way deemed most appropriate by the responsible network administrators, ensuring that the resources are used and/or available as required to support the data management (e.g., backup and restore) of the enterprise or other stakeholder(s) associated with the network. - Each of the queues Q1-Q5 has associated with it a pending request area, identified in
FIG. 4 asareas - In the example shown in
FIG. 4 , all of the tape drives in thenetwork environment 100 ofFIG. 1 have been assigned to a queue, and all of the requests that may be generated with respect to hosts (clients) innetwork environment 100 have been assigned to a request category, each of which has in turn been assigned to a queue. However, in other embodiments, a user may choose not to create a queue for each device and/or type of request, and to instead create one or more queues to handle a subset of the requests associated with the network environment, such as to ensure that the most critical requests are serviced in a timely manner. For example, referring further toFIG. 4 , in some embodiments it may be sufficient or advantageous to define only queues Q3 and Q5, to allocate resources on theSAN 136 ofFIG. 1 . In such a case, requests not associated with a request category and/or queue will be handled by a default queue, such as a default queue for the data zone from which the request originated. -
FIG. 5 is a flowchart illustrating a process used in some embodiments to receive requests and assign them to a queue, as instep 204 ofFIG. 2 . Instep 502, a request for a removable storage media resource is received. The request may comprise, for example, a request that a particular volume of storage media (e.g., a specified tape) be mounted on a particular device (e.g., tape drive). Instep 504, the request is associated with a request category and a data zone. In some embodiments, the request may indicate the request category and/or data zone to which it relates. In some embodiments, the request may comprise other information that may be used to associate the request with a request category and/or data zone, such as information identifying a pool, a client (host) system, or the data or data type to which the request relates, or indicating the backup or other application that generated the request. In some embodiments, not shown inFIG. 5 , if no request category is indicated (or the request category cannot be determined based on other information), the request is assigned to a default queue for the data zone to which the request relates. Instep 506, the priority level of the request is determined. In some embodiments,step 506 may comprise receiving with the request an indication of the priority of the request. In some embodiments, the priority may be determined at least in part by the type of operation associated with the request (e.g., a request associated with a restore operation may have higher priority than a request associated with a backup operation). In some embodiments, the priority may be determined at least in part based on the data and/or host to which the request relates. Instep 508, the request is place in the appropriate place in line in the appropriate queue. Step 508 may comprise placing the request in the queue that corresponds to the request category and data zone associated with the request, as determined instep 504. Step 508 may comprise placing the request in the queue in a place determined at least in part by the priority determined instep 506. For example, a request may be placed in the queue in a position ahead of pending requests having a lower priority and behind pending requests having higher priority. In some embodiments, requests of the same priority are handled on a first-in-first-out (FIFO) basis. In some embodiments, once a request is placed within a queue in the appropriate place a user may alter the position of the request within the queue. A user interface may be provided to facilitate such altering of the order within a queue, such as by allowing a user to click on and drag a request from a current position in the queue to a new position. -
FIG. 6 is a flow chart illustrating a process used in some embodiments to service requests in accordance with their assigned queue and priority, as instep 206 ofFIG. 2 . Instep 602, an indication is received that a resource associated with a queue is available. Such an indication may comprise, e.g., an indication from the backup application that a previously serviced request is complete. In other embodiments, the indication may comprise an indication received from the library that a tape dismount operation with respect to the drive in question has been completed. Instep 604, the next request in line in the queue is identified from among the requests pending in the queue. In some embodiments, the requests are stored in the queue in the order in which they are to be serviced, based on the nature of the request and/or other priority information, as described above. In such embodiments,step 604 comprises reading from the first (i.e., next to be serviced) position in the queue information about the next request due to be serviced. Instep 606, the request identified instep 604 is serviced, e.g., by causing a tape specified in the request to be mounted on a drive specified in the request (and/or a drive associated with the queue, if none is specified in the request). - Requests in a default queue may be handled similarly to requests in queues to which resources have been allocated, except that the resources (e.g., drives) available to service such requests are those to which the host associated with each respective request has a connection and that are not allocated to another queue.
- Using the techniques described herein, removable media storage resources (e.g., tape drives) may be allocated to one or more queues, dedicating them to servicing requests associated with the respective queue to which each device is assigned. This provides network administrators with the ability to ensure that resources are used in an optimal manner and that resources are available in an adequately timely manner to service mission critical requests.
- Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
Claims (22)
1. A method for processing requests for media resources, comprising:
defining a queue;
allocating a media resource to the queue; and
associating a media resource request with the queue.
2. The method of claim 1 , wherein associating a media resource request with the queue comprises associating the media resource request with a request category associated with the queue.
3. The method of claim 1 , further comprising
defining a request category; and
associating the request category with the queue;
wherein associating a media resource request with the queue comprises associating the media resource request with the request category.
4. The method of claim 1 , wherein the media resource comprises a media storage device.
5. The method of claim 1 , wherein the media resource comprises a tape drive.
6. The method of claim 1 , wherein the media resource request comprises a request to mount a volume of removable storage media on the media resource.
7. The method of claim 1 , further comprising receiving the media resource request from a host.
8. The method of claim 1 , further comprising receiving the media resource request from a backup application.
9. The method of claim 1 , wherein the media resource is allocated exclusively to the queue.
10. The method of claim 1 , wherein the queue comprises a first queue, the media resource comprises a first media resource, and the media resource request comprises a first media resource request, further comprising:
receiving a second media resource request;
determining that the second media resource request is not associated with the first queue; and
associating the second media resource request with a default queue.
11. The method of claim 10 , further comprising associating a second media resource with the default queue.
12. The method of claim 1 , further comprising assigning the media resource request a place in the queue.
13. The method of claim 12 , wherein assigning the media resource request a place in the queue comprises determining whether the media resource request has a higher priority than any other media resource request currently pending in the queue.
14. The method of claim 12 , wherein assigning the media resource request a place in the queue comprises placing the media resource request in line behind previously-received media resource requests pending in the queue unless the media resource request has a higher priority than one or more previously-received media resource requests pending in the queue.
15. The method of claim 12 , further comprising receiving an indication that the media resource request should be moved to a different place in the queue than the place currently assigned.
16. The method of claim 1 , further comprising:
receiving an indication that the media resource is available;
selecting from the queue a selected request to be serviced by the media resource; and
servicing the selected request.
17. The method of claim 1 , wherein the media resource request is associated with the queue based at least in part on data included in the request.
18. The method of claim 1 , wherein the media resource request is associated with a set of data and the media resource request is associated with the queue based at least in part on the set of data to which the request relates.
19. The method of claim 1 , wherein the media resource request is associated with a client on which a set of data associated with the media resource request is stored and the media resource request is associated with the queue based at least in part on the client with which the media resource request is associated.
20. The method of claim 1 , wherein the media resource request is associated with an application that generated the media resource request and the media resource request is associated with the queue based at least in part on the application which generated the media resource request.
21. A system for processing requests for media resources, comprising:
a processor configured to:
define a queue;
allocate a media resource to the queue; and
associate a media resource request with the queue; and
a memory configured to store the media resource request and other data associated with the queue.
22. A computer program product for processing requests for media resources, the computer program product being embodied in a computer readable medium and comprising computer instructions for:
defining a queue;
allocating a media resource to the queue; and
associating a media resource request with the queue.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/524,494 US20070016825A1 (en) | 2002-12-18 | 2006-09-19 | Resource allocation aware queuing of requests for media resources |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US43447102P | 2002-12-18 | 2002-12-18 | |
US10/737,170 US7131025B2 (en) | 2002-12-18 | 2003-12-16 | Resource allocation aware queuing of requests for media resources |
US11/524,494 US20070016825A1 (en) | 2002-12-18 | 2006-09-19 | Resource allocation aware queuing of requests for media resources |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/737,170 Continuation US7131025B2 (en) | 2002-12-18 | 2003-12-16 | Resource allocation aware queuing of requests for media resources |
Publications (1)
Publication Number | Publication Date |
---|---|
US20070016825A1 true US20070016825A1 (en) | 2007-01-18 |
Family
ID=32685312
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/737,170 Active 2025-03-17 US7131025B2 (en) | 2002-12-18 | 2003-12-16 | Resource allocation aware queuing of requests for media resources |
US11/524,494 Abandoned US20070016825A1 (en) | 2002-12-18 | 2006-09-19 | Resource allocation aware queuing of requests for media resources |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/737,170 Active 2025-03-17 US7131025B2 (en) | 2002-12-18 | 2003-12-16 | Resource allocation aware queuing of requests for media resources |
Country Status (5)
Country | Link |
---|---|
US (2) | US7131025B2 (en) |
EP (1) | EP1573539A4 (en) |
JP (1) | JP2006511870A (en) |
AU (1) | AU2003299668A1 (en) |
WO (1) | WO2004059486A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120310894A1 (en) * | 2011-06-03 | 2012-12-06 | Apple Inc. | Methods and apparatus for interface in multi-phase restore |
US20130132581A1 (en) * | 2011-11-21 | 2013-05-23 | Verizon Patent And Licensing Inc. | Video service manager |
US9465696B2 (en) | 2011-06-03 | 2016-10-11 | Apple Inc. | Methods and apparatus for multi-phase multi-source backup |
US9483365B2 (en) | 2011-06-03 | 2016-11-01 | Apple Inc. | Methods and apparatus for multi-source restore |
US9542423B2 (en) | 2012-12-31 | 2017-01-10 | Apple Inc. | Backup user interface |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8561076B1 (en) * | 2004-06-30 | 2013-10-15 | Emc Corporation | Prioritization and queuing of media requests |
US7929686B2 (en) * | 2005-04-27 | 2011-04-19 | At&T Intellectual Property Ii, L.P. | System and method for managing request priority in a telecommunications network |
US7418531B2 (en) * | 2005-05-04 | 2008-08-26 | Pillar Data Systems, Inc. | Quality of service for data storage volumes |
JP5250955B2 (en) * | 2006-10-05 | 2013-07-31 | 富士通株式会社 | Data processing system backup control apparatus and system |
US8219657B2 (en) * | 2008-06-13 | 2012-07-10 | Microsoft Corporation | Automatic request categorization for internet applications |
US8948906B2 (en) * | 2008-08-14 | 2015-02-03 | Spectra Logic Corporation | Robotic storage library with queued move instructions and method of queuing such instructions |
US8457778B2 (en) * | 2008-08-15 | 2013-06-04 | Spectra Logic Corp. | Robotic storage library with queued move instructions and method of queuing such instructions |
US9141446B2 (en) * | 2008-10-24 | 2015-09-22 | Sap Se | Maintenance of message serialization in multi-queue messaging environments |
US8340810B2 (en) * | 2008-10-31 | 2012-12-25 | Spectra Logic Corp. | Robotic storage library with queued move instructions and method of queuing such instructions |
US8666537B2 (en) * | 2008-10-31 | 2014-03-04 | Spectra Logic, Corporation | Robotic storage library with queued move instructions and method of queing such instructions |
US8423517B2 (en) * | 2010-02-09 | 2013-04-16 | Google Inc. | System and method for determining the age of objects in the presence of unreliable clocks |
US8862617B2 (en) * | 2010-02-09 | 2014-10-14 | Google Inc. | System and method for replicating objects in a distributed storage system |
US8615485B2 (en) * | 2010-02-09 | 2013-12-24 | Google, Inc. | Method and system for managing weakly mutable data in a distributed storage system |
US8380659B2 (en) | 2010-02-09 | 2013-02-19 | Google Inc. | Method and system for efficiently replicating data in non-relational databases |
US8868508B2 (en) * | 2010-02-09 | 2014-10-21 | Google Inc. | Storage of data in a distributed storage system |
US9305069B2 (en) * | 2010-02-09 | 2016-04-05 | Google Inc. | Method and system for uploading data into a distributed storage system |
US8874523B2 (en) * | 2010-02-09 | 2014-10-28 | Google Inc. | Method and system for providing efficient access to a tape storage system |
US8341118B2 (en) * | 2010-02-09 | 2012-12-25 | Google Inc. | Method and system for dynamically replicating data within a distributed storage system |
US8560292B2 (en) * | 2010-02-09 | 2013-10-15 | Google Inc. | Location assignment daemon (LAD) simulation system and method |
US20110307898A1 (en) * | 2010-06-10 | 2011-12-15 | Siemens Aktiengesellschaft | Method and apparatus for efficiently distributing hardware resource requests to hardware resource offers |
US8682471B2 (en) | 2010-09-27 | 2014-03-25 | Spectra Logic Corporation | Efficient magazine moves |
US8615322B2 (en) | 2010-09-27 | 2013-12-24 | Spectra Logic Corporation | Efficient moves via dual pickers |
US10089272B2 (en) * | 2016-02-22 | 2018-10-02 | Dell Products, Lp | Data-category switch module in the control plane for use with internet of things devices |
US11023174B2 (en) * | 2019-09-12 | 2021-06-01 | International Business Machines Corporation | Combining of move commands to improve the performance of an automated data storage library |
US10929200B1 (en) * | 2019-09-16 | 2021-02-23 | International Business Machines Corporation | Live runtime infrastructure orchestration |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6230200B1 (en) * | 1997-09-08 | 2001-05-08 | Emc Corporation | Dynamic modeling for resource allocation in a file server |
US6338112B1 (en) * | 1997-02-21 | 2002-01-08 | Novell, Inc. | Resource management in a clustered computer system |
US6760808B2 (en) * | 1997-12-24 | 2004-07-06 | Avid Technology, Inc. | Computer system and process for transferring multiple high bandwidth streams of data between multiple storage units and multiple applications in a scalable and reliable manner |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5155854A (en) * | 1989-02-03 | 1992-10-13 | Digital Equipment Corporation | System for arbitrating communication requests using multi-pass control unit based on availability of system resources |
US5414851A (en) * | 1992-06-15 | 1995-05-09 | International Business Machines Corporation | Method and means for sharing I/O resources by a plurality of operating systems |
US5544318A (en) * | 1993-04-16 | 1996-08-06 | Accom, Inc., | Asynchronous media server request processing system for servicing reprioritizing request from a client determines whether or not to delay executing said reprioritizing request |
US5524085A (en) | 1994-09-12 | 1996-06-04 | Xerox Corporation | Multimedia job tickets for printing machines |
US5787482A (en) * | 1995-07-31 | 1998-07-28 | Hewlett-Packard Company | Deadline driven disk scheduler method and apparatus with thresholded most urgent request queue scan window |
JP3813671B2 (en) * | 1996-10-30 | 2006-08-23 | 株式会社東芝 | Disk array device for multimedia server |
US6338074B1 (en) * | 1997-07-23 | 2002-01-08 | Filenet Corporation | System for enterprise-wide work flow automation |
US6141707A (en) * | 1998-05-28 | 2000-10-31 | Emc Corporation | Input/output request allocation by establishing master command queue among plurality of command queues to receive and store commands, determine logical volume, and forwarding command to determined logical volume |
WO2000004483A2 (en) * | 1998-07-15 | 2000-01-27 | Imation Corp. | Hierarchical data storage management |
US6516423B1 (en) * | 1999-10-21 | 2003-02-04 | Ericsson Inc. | System and method for providing multiple queue redundancy in a distributed computing system |
GB9928503D0 (en) * | 1999-12-03 | 2000-02-02 | Ibm | Resource allocation in data processing systems |
US20040010592A1 (en) * | 2000-01-14 | 2004-01-15 | Carver Andrew Richard | Resource allocation |
US6684250B2 (en) * | 2000-04-03 | 2004-01-27 | Quova, Inc. | Method and apparatus for estimating a geographic location of a networked entity |
US6920447B2 (en) * | 2001-02-15 | 2005-07-19 | Microsoft Corporation | Concurrent data recall in a hierarchical storage environment using plural queues |
US20020133530A1 (en) | 2001-03-15 | 2002-09-19 | Maarten Koning | Method for resource control including resource stealing |
US20030009553A1 (en) * | 2001-06-29 | 2003-01-09 | International Business Machines Corporation | Method and system for network management with adaptive queue management |
US20030204551A1 (en) | 2002-04-30 | 2003-10-30 | Ling Chen | System and method for providing media processing services |
-
2003
- 2003-12-16 EP EP03799952A patent/EP1573539A4/en not_active Withdrawn
- 2003-12-16 JP JP2004563678A patent/JP2006511870A/en not_active Withdrawn
- 2003-12-16 AU AU2003299668A patent/AU2003299668A1/en not_active Abandoned
- 2003-12-16 WO PCT/US2003/040223 patent/WO2004059486A1/en active Application Filing
- 2003-12-16 US US10/737,170 patent/US7131025B2/en active Active
-
2006
- 2006-09-19 US US11/524,494 patent/US20070016825A1/en not_active Abandoned
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6338112B1 (en) * | 1997-02-21 | 2002-01-08 | Novell, Inc. | Resource management in a clustered computer system |
US6230200B1 (en) * | 1997-09-08 | 2001-05-08 | Emc Corporation | Dynamic modeling for resource allocation in a file server |
US6760808B2 (en) * | 1997-12-24 | 2004-07-06 | Avid Technology, Inc. | Computer system and process for transferring multiple high bandwidth streams of data between multiple storage units and multiple applications in a scalable and reliable manner |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20120310894A1 (en) * | 2011-06-03 | 2012-12-06 | Apple Inc. | Methods and apparatus for interface in multi-phase restore |
US9317369B2 (en) | 2011-06-03 | 2016-04-19 | Apple Inc. | Methods and apparatus for multi-phase restore |
US9411687B2 (en) * | 2011-06-03 | 2016-08-09 | Apple Inc. | Methods and apparatus for interface in multi-phase restore |
US9465696B2 (en) | 2011-06-03 | 2016-10-11 | Apple Inc. | Methods and apparatus for multi-phase multi-source backup |
US9483365B2 (en) | 2011-06-03 | 2016-11-01 | Apple Inc. | Methods and apparatus for multi-source restore |
US9904597B2 (en) | 2011-06-03 | 2018-02-27 | Apple Inc. | Methods and apparatus for multi-phase restore |
US20130132581A1 (en) * | 2011-11-21 | 2013-05-23 | Verizon Patent And Licensing Inc. | Video service manager |
US9118431B2 (en) * | 2011-11-21 | 2015-08-25 | Verizon Patent And Licensing Inc. | Video service manager |
US9542423B2 (en) | 2012-12-31 | 2017-01-10 | Apple Inc. | Backup user interface |
Also Published As
Publication number | Publication date |
---|---|
EP1573539A1 (en) | 2005-09-14 |
WO2004059486A1 (en) | 2004-07-15 |
US7131025B2 (en) | 2006-10-31 |
WO2004059486A9 (en) | 2004-08-19 |
US20040199810A1 (en) | 2004-10-07 |
JP2006511870A (en) | 2006-04-06 |
AU2003299668A1 (en) | 2004-07-22 |
EP1573539A4 (en) | 2008-06-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7131025B2 (en) | Resource allocation aware queuing of requests for media resources | |
JP5285128B2 (en) | Maintaining information in one or more virtual volume aggregates containing multiple virtual volumes | |
JP4220724B2 (en) | Storage device | |
US6023709A (en) | Automated file error classification and correction in a hierarchical storage management system | |
US6199146B1 (en) | Storage management system and method for increasing capacity utilization of nonvolatile storage devices using partially filled substitute storage devices for continuing write operations | |
EP1540455B1 (en) | Moving data among storage units | |
US7606844B2 (en) | System and method for performing replication copy storage operations | |
US6883076B1 (en) | System and method for providing safe data movement using third party copy techniques | |
CN100390744C (en) | Method and system for error strategy in a storage system | |
US7818530B2 (en) | Data management systems, articles of manufacture, and data storage methods | |
US6952757B2 (en) | Method, system, and program for managing storage units in storage pools | |
EP2689329A1 (en) | Data backup prioritization | |
US6895466B2 (en) | Apparatus and method to assign pseudotime attributes to one or more logical volumes | |
US8751739B1 (en) | Data device spares | |
US20100107161A1 (en) | Method of Improving or Managing Performance of Storage System, System, Apparatus, and Program | |
US6279074B1 (en) | Contention handling for task requests to storage devices within a host system | |
US7089392B2 (en) | Method, system, and program for allocating storage units to a data set | |
US7080223B2 (en) | Apparatus and method to manage and copy computer files | |
US8561076B1 (en) | Prioritization and queuing of media requests | |
US7363447B1 (en) | System and method for providing safe data movement using third party copy techniques |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |