Patent Application
20080005475
A base deck 102 mates with a top cover (not shown) to form an enclosed housing. A spindle motor 104 is mounted within the housing to controllably rotate media 106, preferably characterized as magnetic recording discs.
A controllably moveable actuator 108 moves an array of read/write transducers 110 adjacent tracks defined on the media surfaces through application of current to a voice coil motor (VCM) 112. A flex circuit assembly 114 provides electrical communication paths between the actuator 108 and device control electronics on an externally mounted printed circuit board (PCB) 116.
Remote users respectively access the fabric 130 via personal computers (PCs) 132, 134, 136. In this way, a selected user can access the storage space 122 to write or retrieve data as desired.
The devices 100 and the controllers 124, 126 are preferably incorporated into a multi-device array (MDA). The MDA preferably uses one or more selected RAID (redundant array of independent discs) configurations to store data across the devices 100. Although only one MDA and three remote users are illustrated in
Policy processors 156, 158 execute a real-time operating system (RTOS) for the controller 140 and communicate with the respective ISPs 142, 144 via PCI busses 160, 162. The policy processors 156, 158 can further execute customized logic to perform sophisticated processing tasks in conjunction with the ISPs 142, 144 for a given storage application. The ISPs 142, 144 and the policy processors 156, 158 access memory modules 164, 166 as required during operation.
A number of list managers, denoted generally at 170 are used for various data and memory management tasks during controller operation, such as cache table management, metadata maintenance, and buffer management. The list managers 170 preferably perform well-defined albeit simple operations on memory to accomplish tasks as directed by the FCCs 168. Each list manager preferably operates as a message processor for memory access by the FCCs, and preferably executes operations defined by received messages in accordance with a defined protocol.
The list managers 170 respectively communicate with and control a number of memory modules including an exchange memory block 172, a cache tables block 174, buffer memory block 176 and SRAM 178. The function controllers 168 and the list managers 170 respectively communicate via a cross-point switch (CPS) module 180. In this way, a selected function core of controllers 168 can establish a communication pathway through the CPS 180 to a corresponding list manager 170 to communicate a status, access a memory module, or invoke a desired ISP operation.
Similarly, a selected list manager 170 can communicate responses back to the function controllers 168 via the CPS 180. Although not shown, separate data bus connections are preferably established between respective elements of
The controller architecture of
To further enhance processing efficiency, a novel storage management methodology is preferably employed by the controllers 124, 126 with regard to “hot data.” The term hot data generally refers to data stored within the storage array 122 for which data accesses (reads and/or writes) are carried out on a relatively frequent basis; that is, data for which there is a relatively high level of host interest as compared to other, “non-hot” data.
Conventional data management techniques generally dictate that hot data should be balanced or otherwise separated and distributed across different locations within the storage array, to reduce the frequency of hits to any particular area.
By contrast, preferred embodiments of the present invention generally operate to form a virtual hot space to store hot data. The virtual hot space generally comprises one or more hot data zones each of which extends across storage media of a plurality of arrayed storage devices over a selected seek range less than an overall radial width of said media.
The hot data are preferably migrated to the hot data zone(s) in response to host level requests to designate certain data as hot data, such as at a host operating system (OS) level through file reference statistics, or through user identification of certain data as hot data such as by a network administrator. Alternatively or additionally, the migration is preferably carried out by the system adaptively identifying data as hot data over time in response to accumulated access statistics, and then moving such hot data from another location of the media to the hot data zone(s).
Infrequently referenced data sets within the hot data zones are further preferably migrated out of these zones to other areas of the media. In this way, the hot data zones accumulate and maintain higher interest data sets, leading to an intentional concentration of media accesses to these areas.
As shown in
Each cache node managed by the CM 190 preferably references some particular SDD, with active SDD structures for a given set of logical discs (subset of the devices 100) being preferably linked in ascending order via a virtual block address (VBA) using a standard forward and backward linked list.
Preferably, the VBA values are aligned with the RAID data organization using a grid system sometimes referred to as a RAID Allocation Grid System (RAGS). Generally, any particular collection of blocks belonging to the same RAID strip 198 (e.g., all of the data contributing to a particular parity set) will be assigned to a particular reliable storage unit (RSU) on a particular sheet.
A book consists of a number of sheets and is constructed from multiple contiguous sets of blocks from different devices 100. Based on the actual sheet and VBA numbers, the books can be further sub-divided into zones, indicating the particular device or device set (when redundancy is employed).
Each SDD 192 preferably includes variables (parameters) that indicate various states of the data. SDD variables that are preferably utilized in accordance with preferred embodiments include access history, last offset, last block, timestamp data (time of day, TOD), RAID level employed, stream parameters, and speculative data status.
The access history of the SDD 192 preferably provide a relative measure of a rate at which accesses are made to the data associated with the SDD. For example, an accesses variable can be an incremental count that is updated upon each access to the data defined by the SDD. The accesses variable thus provides an indication of host interest in the data in this locality; under normal circumstances, a higher existing number of accesses might produce a higher likelihood that more accesses will occur in the near future.
The TOD variable generally provides an indication of elapsed time since the most recent access. By subtracting the TOD variable from the current time, an aging assessment can be made on how frequently (or infrequently) the SDD is being accessed.
The stream parameters generally provide stream count and stream size values relating to successively issued requests for data from the storage array that fall into a concurrent sequence (a “stream”). When a request just follows a previous request as determined by the VBA matching the previous last VBA based on the last offset and last block values, the stream count is incremented and the stream size is adjusted to match the new overall range. The speculative data status value generally identifies the associated data ranges of speculatively retrieved data within a stream.
A logical disk descriptor (LDD) 200 preferably provides data on a logical disc basis, which can span several adjacent SDDs in the virtual space created on the media 106 of a given set of grouped devices 100.
Preferably, during normal operations the cache manager 190 operates to service host read and write operations to transfer data between the storage devices 100 and an associated host (e.g., PCs 132, 134, 136). During a read operation, if a cache hit can not be made, the requested data are retrieved from the media 106 to cache memory 202 for subsequent transfer to the host. Speculative non-requested data may also be retrieved and retained in the cache memory as desired.
During write operations, writeback data from the associated host are stored in the cache memory 202 and a command complete status is communicated to the host to free the host to continue with additional processing. The CM 190 then schedules the writing of the cached writeback data to the appropriate locations on the media 106 of the storage devices 100 at a later time.
A timer 204 preferably characterized as a free running counter provides timing information to assess aging of the various cached requested and speculative readback data, as well as the aging of the cached writeback data.
A storage manager 206 operates in conjunction with the cache manager 190 to assess access history trends. The storage manager 206 can be implemented in hardware or software as desired, such as part of the FCCs 168 or policy processors 156, 158. The storage manager 206 generally serves as a monitoring routine to track access activity with the devices 100. Access statistics are preferably accumulated for a selected period of time, as represented at block 208. The storage manager 206 can further operate in response to configuration inputs supplied by a host, such as a host application or operating system, via communication path 210.
Generally, the storage manager 206 operates to migrate data within the array to different locations to improve operational efficiencies. This will be explained in greater detail with reference to
The media surface is divided into radially concentric logical groups 212. The groups 212, also referred to herein as zones, are denoted 1 to n from an outermost diameter (OD) to an innermost diameter (ID) of the media 106 in each of the associated devices 100. Preferably, the zones correspond to selected cylinders (e.g., the respective blocks axially aligned on multiple adjacent media surfaces), although such is not necessarily required.
Each zone 212 comprises a selected number of tracks on which sectors (logical blocks) of selected size are formed (e.g., 512 bytes, 4096 bytes, etc.). The zones 212 can all have a common maximum data capacity, or can have different respective data capacities. The zones 212 each thus represent a contiguous, selected seek range for the associated transducer 110 on each of the respective media surfaces of each of the devices 100.
Each zone 212 in
As further shown in
Under normal operational loading, it is contemplated that certain types of data will be requested on a substantially higher access rate basis than other types of data, such as in accordance with the well-known 80-20 Pareto Rule (i.e., around 80% of the accesses may be for only about 20% of the data). With suitable parametric selections, the hot books can be selected from consecutive LBA ranges with highly concentrated seek ranges with respect to the overall width of the media, such as ⅛ of the overall media width. Thus, by placing this highly accessed data within a reduced seek range such as book 1 in
Preferably, the hot books are set up to confine accesses to a portion of the media surfaces, such as ⅛th, ¼th, ⅜th, etc. In some preferred embodiments, system administrators or other personnel can designate certain types of highly referenced data to be specifically “earmarked” for the hot book(s). A system operating system (OS) can also be configured to use on-demand sparse allocation techniques to specifically place frequently referenced data to the hot book(s).
The storage manager 206 further preferably performs statistical analyses or other empirical analyses of the access statistics from block 208 accumulated during operation. When a data set is identified as a candidate for migration to the hot books, if stored elsewhere on the media 106, the storage manager 206 schedules the appropriate movement of the associated data to the hot books (e.g., from some other non-hot book to book 1).
The data moved can be any suitable set or sets of data. The data can be migrated in fixed sized blocks, such as 8 MB (64 SDDs), or different sized blocks can be migrated at different times. In some preferred embodiments, the moved data is provided with a selected RAID configuration, and this configuration remains unchanged after the migration. Alternatively, new RAID configurations can be applied to the units of data that are moved upon migration. Suitable thresholds can be established and adaptively adjusted as required to aid in the designation of data as candidates for movement to the hot book(s).
Similarly, the access statistics further preferably maintain a history of accesses to the hot data once stored in the hot book(s). In this way, if a certain data set has not been accessed at a level sufficient to continue the designation thereof as hot data, the CM 190 can be instructed to schedule a move of such data out of the hot zone to another location on the media 106.
The decision to move selected sets of infrequently accessed data out of the hot data zone can take into account the manner in which the data were first designated as hot data; for example, data migrated in response to the access statistics are preferably more likely to be subsequently moved out as compared to data designated as hot at the host level.
Of course, host level designations can also be specifically made to declassify formerly hot data as non-hot data, in which case the storage manager 206 operates to schedule the subsequent migration of the formerly hot data out of the hot data zone. The system can also be configured to provide indications to the host that data identified at the host level as hot data are being infrequently accessed, along with a request for permission from the host to migrate said data out of the hot data zone.
Preferably, the data storage capacity of the hot book zones 212 is larger than the associated allocatable cache memory 202; that is, it is contemplated that there will be more hot data than can be continuously maintained in the cache memory, and the amount of hot data will be larger than the associated cache capacity. This is not a problem, however; if cache hits are not available for a given set of requested data, disc I/O accesses will take place as before. The physical proximity of the hot data on the media 106, however, will generally operate to advantageously reduce seek latencies in servicing such requests.
The cache manager 190 preferably operates in a conventional fashion to carry out cache management and retention policies to handle on-going transfers, with the addition that readback data from (or to) a hot zone may be retained in cache longer than data to the remaining zones, or retained due to fewer accesses, all other factors being equal.
Moreover, the storage manager 206 is preferably further adapted to operate in conjunction with the cache manager 190 to give priority to accesses associated with the hot book(s), on the basis that such data have been deemed to exhibit a higher presumed priority as compared to data in other books. Thus, as the cache manager 190 operates to set up and service a command queue for data transfers with the devices 100, a weighting can be applied to commands associated with the hot books. Using the aforementioned 80-20 example, if about 20% of the data stored in the array 122 is deemed to represent hot data, then the cache manager 190 will preferably be configured to spend roughly about 80% of the time servicing data transfers to the hot book zones, and about 20% of the time servicing transfers to the remaining zones.
The system is initially configured at step 302. Preferably, this will include preparation for the system to accept and service data transfer requests, as well as to load other parameters such as the previously accumulated access statistics for the storage manager 206. If hot zones have not already been designated and populated with hot data, then this step can include initial designation of the virtual hot space to which hot data are to be accumulated, with the virtual hot space identified as the corresponding hot zone(s) on the storage media on each of the associated devices 100 with the selected seek range as discussed above.
Normal system operation commences at step 304, which will preferably include the servicing of host/array data transfers. As described above, this preferably includes read data requests from a selected host to transfer selected data sets from the devices 100 to the host, as well as writeback data requests to write data to the devices 100. Access history statistics are preferably accumulated on an on-going basis during these operations at step 306.
Hot data are periodically migrated to the hot data zone(s) at step 308. This preferably occurs as described above through host level requests (such as at the OS level or by user designation), or through the ongoing analysis and ranking of data accesses by the storage manager 206. At step 310, data that have previously been denoted as hot data continue to be monitored by the storage manager 206 and, as required, migrated away from the hot data zones to other non-hot zones on the media 106.
In this way, the system is highly adaptive to changes in operational loading requirements, and can be readily scalable by applications or user input. Much of the operation of the hot data zone methodology can be transparent to the user, while providing significantly improved, sustained I/O rates.
An advantage of the various preferred approaches discussed herein is that, generally, hot data are generally guaranteed to be within a selected, reduced seek range on each of the associated media surfaces of the associated storage devices 100, which will tend to significantly improve transfer performance for such data in response to random read and write operations with such data. The approach can readily be used in accordance with the aforementioned RAGS implementation, as well as with other implementations including formula RAID.
While preferred embodiments presented herein have placed the hot data zone(s) adjacent the ODs of the media of the associated storage devices 100, it will be apparent that such is not required; that is, the virtual hot space can be mapped to any suitable band on the media including near the IDs. The hot zone can further vary in radial location from device to device if so desired
In further preferred embodiments, multiple gradients of “hotness” are assigned to the virtual hot space. For example, some data can be designated as “hot” and stored to a first zone (e.g., zone 1 in
In such case, a second zone (e.g., zones 2 and 3 in
In this way, assuming n=8 for the present example, it follows that the hot data are stored in zone 1 (constituting substantially a ⅛ seek range), the warm data are stored in zones 2-3 (constituting a ¼ seek range) and the cold data are stored in zones 4-8 (constituting a ⅝ seek range). The virtual hot space thus guarantees that the transducers 110 will generally spend most of the time within a ⅜ seek range of the respective media, with periodic excursions to the rest of the media surfaces to service the cold data. Further gradations are envisioned as well (e.g., “cold data,” “warm data,” “hot data,” “hotter data,” “hottest data”) and can be readily implemented as desired.
The hot data zone(s) are preferably sized to provide sufficient storage capacity to handle a number of issues including sparing, RAID configurations and transformations, mirroring, etc. Nevertheless, it will be appreciated that in order to obtain the performance gains discussed above, the hot data on each storage device 100 are preferably limited to the selected, reduced seek range on each media surface.
While preferred embodiments presented herein have been directed to a multi-device array utilizing a plurality of disc drive data storage devices, it will be appreciated that such is merely for purposes of illustration and is not limiting. Rather, the claimed invention can be utilized in any number of various environments to promote efficient data handling.
For purposes of the appended claims, reference to a hot data zone which extends across storage media of a plurality of arrayed storage devices over a selected seek range less than an overall radial width of said media will be understood to cover as at least one media surface in each said device. While the hot data zone may be extended to multiple media surfaces in each device, such is not required. The term “migration” as used herein does not require that the data first be stored to another location of the media.
It is to be understood that even though numerous characteristics and advantages of various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and function of various embodiments of the invention, this detailed description is illustrative only, and changes may be made in detail, especially in matters of structure and arrangements of parts within the principles of the present invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed. For example, the particular elements may vary depending on the particular application without departing from the spirit and scope of the present invention.
