Abstract:
In general, in one aspect, the description includes a method of responding to storage access requests. The method includes defining at least one write area and at least one read-only area, receiving a write request specifying a first address that resides within the at least one read-only area, determining a second address in the write address area, and storing data associating the first address with the second address.

Description:
BACKGROUND 
     The storage capacities of data storage systems have grown enormously. For example, EMC Corporation&#39;s Symmetrix® data storage system can offer storage measured in Terabytes. To offer this storage, a Symmetrix® system pools a collection of physical disks (also referred to as “spindles”). 
     Each physical disk can respond to a limited number of I/O (Input/Output) operations (e.g., read and write requests) in a given time period. The number of I/O operations a physical disk can handle is often measured in IOPS (Input/Output operations per second). To respond to I/O requests quickly and conserve IOPS, many systems use a high-speed cache (pronounced “cash”). For example, a cache can store copies of data also stored on a physical disk. If the system can respond to a request using a copy of data stored in the cache instead of retrieving data from the physical disk, the system has both reduced response time and reduced the I/O burden of the physical disks. 
     A cache can also speed responses to write requests. For example, the Symmetrix® system can store write requests in a cache and defer storage of the information to a physical disk until later. Thus, a host requesting the write operation receives fast confirmation of the write operation from the storage system even though the write operation has not yet completed. 
     SUMMARY 
     In general, in one aspect, the description includes a method of responding to storage access requests. The method includes defining at least one write area and at least one read-only area, receiving a write request specifying a first address that resides within the at least one read-only area, determining a second address in the write address area, and storing data associating the first address with the second address. 
     Embodiments may include one or more of the following features. The method may further include storing information included in the write request at the second address. Determining the second address may include determining the next sequential address of a write area. The method may further include receiving a read request specifying the first address, accessing the data associating the first address and the second address, and requesting information stored at the second address. The method may further include redefining the write area and read area to form at least one new write area and at least one new read area where at least a portion of the new read-only area occupies an area previously occupied by the write area. The method may further include defining a third area for storing a copy of at least one of the read-only areas, copying data stored in at least one of the read-only areas into the third area, and collecting free blocks of the third area. 
     In general, in another aspect, the description includes a computer program product, disposed on a computer readable medium, for responding to storage access requests. The computer program includes instructions for causing a processor to define at least one write area and at least one read-only area, receive a write request specifying a first address that resides within the at least one read-only area, determine a second address in the write address area, and store data associating the first address with the second address. 
     In general, in another aspect, the description includes a method of managing storage. The method includes defining a read-only storage area, a write storage area, and a first garbage storage area. The method also includes repeatedly redirecting write requests for an address within the read-only storage area to the write area, collecting free space in the garbage storage area, and defining a new read-only storage area, a new write storage area, and a new garbage storage area such that the new read-only area includes the previously defined write area and the new write area includes collected free space in the new garbage storage area. 
     Embodiments may include one or more of the following features. The method may further include copying data stored in the new read-only storage area to the new garbage storage area. The storage areas may be physical storage areas. The write requests may specify a physical address. 
     In general, in another aspect, the description includes a system for handling I/O (Input/Output) requests. The system includes a collection of storage disks and a block table associating addresses specified by the I/O requests with addresses of the storage disk. The block table also defines at least one read-only area of the storage disks, at least one write area of the storage disks, and at least one third area of the storage disks. The system also includes instructions for causing a processor to process a read request by accessing the block table to determine the storage disk address associated with the-address specified by the request. The system also includes-instructions for causing a processor to process a write request that specifies a storage disk address corresponding to the at least one read-only area of the storage disks by determining a next location in the at least one write area and storing information in the block table that associates the location in the at least one write area with the storage disk address specified by the write request. 
     Advantages will become apparent in view of the following description, including the figures and the claims. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a diagram of a data storage system. 
     FIGS. 2-5 are diagrams illustrating data storage using read-only and write areas. 
     FIG. 6 is a diagram illustrating free block collection. 
     FIG. 7 is a diagram illustrating redefinition of storage areas. 
     FIGS. 8-14 are diagrams illustrating operation of a data storage system. 
     FIG. 15 is a flow-chart of a process for handling I/O requests. 
    
    
     DETAILED DESCRIPTION 
     Data storage systems often handle a very large number of I/O requests. For example, FIG. 1 illustrates a Symmetrix® data storage system  104  that handles I/O requests received from multiple hosts  100   a - 100   n . As shown, the system  104  includes a cache  106  to speed host  100   a - 100   n  access to data stored by collections of physical disks  110   a - 110   n . The system  104  also includes front-end processors  102   a - 102   n  that process I/O requests received from the host computers  100   a - 100   n . For example, for a read request, the front-end processors  102   a - 102   n  can determine whether the cache  106  currently holds a requested data block. If so, the front-end processors  102   a - 102   n  can quickly satisfy the host computer&#39;s  100   a - 100   n  request using the cached block. If not, the front-end processor  102   a - 102   n  can ask a back-end processor  108   a - 108   n  to load the requested block into the cache  106 . Thus, a read request that the cache  106  cannot satisfy results in a read I/O operation. For a write request, the front-end processors  102   a - 102   n  can store the write data in the cache for subsequent writing to the physical disks  110   a - 110   n  by the back-end processors  108   a - 108   n.    
     Described herein are a variety of techniques that can both enable a storage system, such as the Symmetrix® system, to devote greater resources to responding to read I/O requests and reduce the I/O burden of write requests. Generally speaking, these techniques include the definition of separate read-only and write storage areas and the use of “redirection” to route write requests away from the read-only areas. Freed, at least in part, from the duty of handling write requests, a physical disk storing a read-only area can devote more resources to read requests. This can, in turn, effectively increase the I/O speed of a storage system without requiring alteration or addition of physical storage. 
     To illustrate redirection, FIGS. 2-5 depict a partitioning of physical storage  132  into read-only  128  and write  130  areas. For example, a first set of spindles may be reserved for the read-only area  128  while a second set of spindles may be reserved for the write area  130 . 
     As shown, the read-only area  128  includes two blocks having physical block addresses of “1”  128   a  and “2”  128   b , respectively. Similarly, the write area  130  includes two blocks having physical block addresses of “3”  130   a  and “4”  130   b , respectively. It should be noted that, for the purposes of illustration, FIGS. 2-5 present a greatly simplified data storage environment. That is, instead of a physical storage  132  area totaling four blocks  128   a ,  128   b ,  130   a ,  130   b , physical storage  132  may feature, for example, 256 TB (Terabytes) of memory divided into 4K (Kilobyte) blocks (i.e., 2 36  blocks). 
     As shown in FIG. 2, an I/O system  126  receives I/O requests. For example, the I/O system  126  may receive requests that access to a cache did not satisfy. For instance, as shown, the I/O system  126  has received a read request  120  for a block stored at physical address “1”. Instead of issuing a request for block “1” as specified by the request  120 , the I/O system  126  accesses an I/O block table  124  that correlates the requested address  125   a  with the actual physical storage  132  block address  127   a  of the requested block. In the case shown in FIG. 2, the table  124  indicates that the requested block  125   a  is stored at the first block  128   a  of physical storage  132 . The I/O system  126  can then issue a request to physical storage  132  for the data (“ali”) stored at block “1”  128   a.    
     In the sequence of FIG. 2, translating the requested block address  125   a  to the physical storage  132  block address  127   a  had no apparent affect (i.e., requested block “1” was coincidentally stored at physical block “1”  128   a ). However, introducing this redirection mechanism can enable the I/O system  126  to direct write requests away from the read-only area  128 . For example, in FIG. 3, the I/O system  126  receives a request  134  to write data (“beth”) at block address “2”. Address “2”  128   b  of physical storage  132 , however, currently falls within the address space  128  designated as read-only. Thus, the I/O system  126  determines a physical address of the next free block  130   a  in the write area  130  for storing the data. As shown, the I/O system  126  updates the I/O block table  124  to associate physical storage block address “3”  127   b  with the requested address, “2”  125   b , and instructs  136  physical storage  132  to store the data in physical storage block “3”  130   a.    
     The I/O system  126  can implement such redirection “behind-the-scenes.” For example, a host may have no idea that the data specified for storage at physical block address “2”  128   b  is actually physically stored at block “3”  130   a . For instance, as shown in FIG. 4, when the I/O system  126  receives a read request  138  for the data block stored at address “2”, the I/O system  126  can use the I/O block table  124  to determine the physical location  130   a  of the block. Thus, narrating FIGS. 3 and 4 from a host&#39;s view-point: the host requested storage of “beth” at physical block “2” (FIG. 3) and retrieved “beth” by specifying a read of physical block “2” (FIG.  4 ), exactly as expected by the host. 
     It should be noted that a write request need not specify insertion of new data, but may instead modify previously stored data. As shown in FIG. 5, the I/O system  126  can, again, direct such write requests away from the read-only area  128 . That is, instead of modifying the data stored at the specified address, the I/O system  126  can determine the address of the next free block  130   b  in the write area  130  to store the modified data and update the I/O block table  124  accordingly. For example, a request  144  to change the value of block “1” from “ali” to “carl” causes the system  126  to store “carl” in physical block “4”  130   b  and change the physical address  127   a  associated with address “1”  125   a  from “1” to “4”  127   a.    
     In addition to storage redirection, FIGS. 2-5 also illustrates sequential writing into the write area  130 . That is, for each successive write operation, the system  126  uses the next sequential write area  130  location. Since physical devices generally store nearby blocks more quickly than blocks found at scattered locations, sequential access facilitates fast storage of writes. 
     Eventually, a write area  130  may run out of free blocks (e.g., blocks that do not store current data). However, as shown in FIG. 6, a system can create room for more sequential writes by collecting free blocks of an area  154  together, updating an I/O block table to reflect block rearrangement, and defining a new write area for the collected free blocks. 
     In greater detail, FIG. 6 depicts an I/O block table  150 ,  152  and physical storage area  154 ,  156  before and after aggregation-of free blocks. As shown, an area  154  initially features two free blocks, “2” and “4” interspersed between two used blocks, “1” and “3”. After moving used block “3”  154   c  to physical address block “2”  156   b  and changing the I/O block table entry for block “3” from “3”  150   b  to “2”  152   b  physical storage  156  features a sequential two block area of free blocks, namely, blocks “3” and “4”. The system may define this new collection of free blocks as a new write area and continue handling write operations sequentially. Again, though the system moves blocks around, the corresponding changes to the I/O block table  150 ,  152  enables an I/O system to maintain access to previously stored data. 
     Instead of operating on an active area (e.g., a read-only area) to collect free blocks, a system may create new write space by operating on a copy of active data. This permits the system to coalesce free blocks without interfering with on-going I/O operations. For example, a background process may handle block rearrangement and revision of I/O block table entries (e.g., entries for addresses “5” and “7”) representing the rearrangement. 
     FIG. 7 illustrates such free block collection using a “garbage area” copy of an active area. The garbage area may be assigned to different spindles than the active area to reduce impact on requested I/O operations. 
     In greater detail, FIG. 7 depicts physical storage  162   a  partitioned into an active area and a garbage area. As shown, mirroring  164   a  the garbage area copies the active area blocks into the garbage area and adds I/O block table  160   b  entries for the garbage area. A system can then collect  164   b  free blocks of the garbage area. Next, the system can redefine  164   c  the physical blocks that constitute the active and garbage areas. For example, blocks “5” to “8” of physical storage  162   d  which were previously allocated for the garbage area are now allocated for the active area. Similarly, blocks “1” to “4” of physical storage  162  which were previously allocated for the active area are now allocated for the garbage area. 
     As shown, to reflect the area redefinitions, a system has updated the I/O block table  160   d . If not updated, addresses “1” to “4” of the table  160   d  would refer to physical blocks allocated for the new garbage area instead of the new active area. Thus, the system updates the physical addresses of the table  160   d  to preserve the links to the appropriate areas. That is, after updating, addresses “1” to “4” in the block table  160   d  are associated with physical addresses in the new active area and addresses “5” to “8” are associated with physical addresses in the new garbage area. Again, this ensures that while an I/O system may move physically stored blocks around, the I/O block table  160 , nevertheless, maintains the external presentation of stored data expected by hosts. 
     FIGS. 2-7 illustrated techniques that included the use of an I/O block table to direct write requests away from a read-only area, the collection of free blocks to dynamically form a new write area, the use of a garbage area to collect free blocks in the background, and the redefinition of areas to use the newly collected free blocks for sequential writing. FIGS. 8-14 illustrate operation of a system that combines these techniques. 
     In greater detail, each of FIGS. 8-14 show physical storage  202  and an I/O block table  200  accessed by an I/O system  204 . The table  200  includes a designation of the usage  210  of a physical address as “read-only”, “write”, or “garbage collection”. The table  200  also includes a mapping of an address  208  to a physical block  212 . To reduce the space occupied by the table  200 , the address  208  may not be physically stored, but may instead represent an index into the table  200 . 
     FIG. 8 depicts the state of an on-going system. In this system, the I/O block table  200  usage  210  data defines physical blocks “1” to “4”  214   a - 214   d  as a read-only area, physical blocks “5” and “6”  214   e - 214   f  as a write area, and physical blocks “7” to “10”  214   g - 214   j  as a garbage collection area. Since the I/O block table  200  defines physical storage usage  210 , partitioning physical storage can occur without communicating the partitioning scheme to the physical storage device(s). That is, the intelligence of the system may reside in the I/O block table  200  and associated software  204  (e.g., instructions executed by a back-end processor) rather than requiring modification of a host or physical storage device. The system may, however, use a priori knowledge of physical storage to ensure segregation of the different usage areas on different spindles through-out system operation. 
     As shown in FIG. 9, the I/O system  204  receives a request  216  to insert “carl” at address “2”. As shown in the I/O block table  200 , address “2”  208   b  corresponds to a physical address designated  210  for read-only use. Thus, the I/O system  204  determines the next sequential block  214   e  in the designated write area for storing the data, for example, by incrementing a write area pointer. As shown, the I/O system  204  also updates the I/O block table  200  to designate physical block “5”  212   b  as the physical storage block address for address “2”  208   b.    
     As shown in FIG. 10, the I/O system  204  next receives a request  218  to modify the data of address “3” from “beth” to “dawn”. Again, the I/O block table  200  indicates address “3”  208   c  currently corresponds to a physical address designated for read-only use. Thus, the I/O system  204 , determines the next sequential block in the write area  214   f  and updates the I/O block table  200  accordingly. 
     As shown in FIG. 11, while the I/O system  204  handles read and write requests, the I/O system  204  or another processor may collect free blocks in the garbage area together and correspondingly update the I/O block table  200 . For example, comparing FIG. 10 to FIG. 11, a garbage collection process has moved the storage location of “beth” from physical block address “9”  214   i  to physical block address “8”  214   h  and updated the I/O block table  200  accordingly. 
     As shown in FIG. 12, at some configurable time (e.g., when the current write area nears full), the I/O system  204  can redefine the read-only, write, and garbage areas. As shown, the I/O system  204  changes the designated usage  210  of the I/O block table  200  to define the collected free blocks, physical blocks “9”. and “10”  214   i - 214   j , as the new write area; define the old read-only area, blocks “1” to “4”  214   a - 214   d , as the new garbage area; and define a new read-only area from the old write area and the “compressed” old garbage collection area, blocks “5” to “8”  214   e - 214   h . As shown in FIG. 13, the system  204  updates the I/O block table  200  so that the addresses “1” to “4”  208   a - 208   d  map to the new read-only area blocks  214   e - 214   h . It should be noted that while the I/O block table  200  changes the use  210  designated for a particular physical address  208 , the I/O block table  200  maintains the external view of data. For example, host requests for addresses “1” to “4”  208   a - 208   d  still resolve to physical address  212   a - 212   d  in the newly defined read-only area though the location of the read-only area has changed. 
     It should be noted that while FIGS. 12 and 13 are shown as discrete actions, a system may implement the area redefinition (FIG. 12) and I/O table update (FIG. 13) as a single atomic operation. For example, a substitute I/O block table may be built and swapped-in after completion. 
     As shown in FIG. 14, at some point, the system  204  then mirrors the new read-only area by copying blocks “5” to “8”  214   e - 214   h  into the new garbage area, blocks “1” to “4”  214   a - 214   d , and updates the I/O block table  200  accordingly. The process illustrated in FIGS. 8-14 then repeats anew. 
     To summarize an example of I/O system operation, FIG. 15 illustrates a process  300  for handling I/O requests. As shown, the process  300  designates  302  read-only, write, and garbage areas. The process  300  can direct  306  write requests away from the read-only area, for example, using the I/O block table described above. During this time, the process  300  can mirror  304  the read-only area in the garbage area and coalesce  308  free garbage area blocks. The process  300  then defines  310  new read-only, write, and garbage areas, and repeats. Thus, the process  300  continually, and in real-time, creates collections of free blocks and uses them for sequential write operations. Hence, the process  300  can replace scattered random writes with efficient sequential ones. As described above, the process  300  can also increase the amount of resources dedicated to processing read requests through the use of storage indirection. 
     While described against a backdrop of the Symmetrix® data storage system, the techniques described herein are not limited to a particular hardware or software configuration and may find applicability in a wide variety of computing or processing environments. The techniques may be implemented in hardware or software, or a combination of the two. For example, the techniques may be implemented in ASICs. The techniques may also be implemented in computer programs executing on programmable computers that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. 
     Each program is preferably implemented in high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case the language may be compiled or interpreted language. 
     Each such computer program is preferably stored on a storage medium or device (e.g., CD-ROM, hard disk, or magnetic disk) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described herein. The system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner. 
     Other embodiments are within the scope of the following claims.