Enhanced read-ahead capabilities of storage devices

Abstract

The present invention is entitled "Enhanced Read-Ahead Capability of a Storage Device." In the context of data storage, a method for pre-fetching data before a read request involves receiving a read request and a next read request, and updating metadata corresponding to the read request with a next data storage address corresponding to the next read request. In response to receiving the read request again at a later time, the next data storage address can be read from the read request metadata, and next data can be pre-fetched from the next data storage address before processing the next read request. In addition, the next data can be pre-fetched and stored in a cache buffer during a read queue idle time before another incoming next read request, in response to which the next data can be returned to the host from the buffer rather than being read from non-volatile memory.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is a continuation-in-part of and claims the benefit of priority to U.S. patent application No. 16 / 012,311, filed on June 19, 2018, the entire contents of which are incorporated herein by reference for all purposes as if fully set forth herein. Technical Field

[0003] Aspects of the present disclosure relate to the field of storage devices, and more particularly, to enhanced read-ahead capabilities that increase the speed of read operations. Background Art

[0004] As the speed of central processing units, graphics processors, and other processing elements increases, storage devices have become a bottleneck affecting the overall performance of computing systems. The speed of solid-state drives (SSDs) relative to hard disk drives (HDDs) has alleviated this problem to some extent. However, a given SSD can still slow down the host computer, and the performance of different SSDs can vary significantly.

[0005] The relative performance of storage devices can be evaluated based on a variety of factors, such as the capacity of a given device and its read and write speeds. While most write speeds have improved over time, read times have always been the key factor limiting storage device performance. Sequential read technologies have achieved some speed improvements, such as increased switching rates, but at the expense of increased power consumption.

[0006] Random reads present a particular challenge to the goal of speed. Compared to sequential reads, which allow large, contiguous blocks of data to be read from adjacent locations on the media, random reads seek data spread across various, non-adjacent locations on the media. Consequently, random reads introduce latency into the read process, impacting the overall performance of both the storage device and its associated host. Summary of the Invention

[0007] This article discloses a read-ahead technique to increase the speed at which storage devices read data. Data for a given write operation can be written to the storage device so that the location of the next write is stored along with the data. Later, when data is read from the storage device, additional data can be pre-fetched from the location that was written along with the data. If the next location is the target of a subsequent read operation, the additional data can be immediately returned to the host because the data has already been read from the location where it was stored. This process thus speeds up subsequent read operations.

[0008] In the context of data storage, a method for pre-fetching data in advance of a read request involves receiving a read request and a next read request, and updating metadata corresponding to the read request with a next data storage address corresponding to the next read request. In response to receiving the read request again later, the next data storage address can be read from the read request metadata, and next data can be pre-fetched from the next data storage address before processing the next read request. Furthermore, the next data can be pre-fetched and stored in a cache buffer during a read queue idle time before another incoming next read request, in response to which the next data can be returned to the host from the buffer rather than being read from non-volatile memory. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Many aspects of the present disclosure may be better understood with reference to the following drawings. The components in the drawings are not necessarily drawn to scale, with emphasis placed on clearly illustrating the principles of the present disclosure. Additionally, in the drawings, like reference numerals refer to corresponding parts throughout the several views. Although several embodiments have been described in conjunction with these drawings, the present disclosure is not limited to the embodiments disclosed herein. Rather, it is intended to cover all alternatives, modifications, and equivalents.

[0010] Figure 1 A computing system in a specific implementation is shown.

[0011] Figure 2 The writing process in a specific implementation is shown.

[0012] Figure 3 The reading process in a specific implementation is shown.

[0013] Figure 4 The operational scenarios in the specific implementation are shown.

[0014] Figure 5 A computing system in a specific implementation is shown.

[0015] Figure 6 The writing process in a specific implementation is shown.

[0016] Figure 7 The reading process in a specific implementation is shown.

[0017] Figure 8 An operational architecture for a specific implementation is shown.

[0018] Figures 9A to 9B An operational architecture for a specific implementation is shown.

[0019] Figure 10 The power control process in a specific implementation is shown.

[0020] Figure 11 A simplified computing system architecture is shown in a specific implementation.

[0021] Figure 12 A method for reducing the reading time in a specific implementation is shown.

[0022] Figure 13 The method of pre-acquiring data in a specific implementation is shown.

[0023] Figure 14 A method for pre-acquiring data into a read queue in a specific implementation is shown. DETAILED DESCRIPTION

[0024] This article discloses an improved storage device with enhanced read-ahead capability. In various implementations, read time is reduced (and speed is increased) by predicting which address will be read next after a given read operation. Data at that address can be pre-fetched before subsequent read requests for that address.

[0025] The predicted address can be derived from information stored about write commands as they appear in the queue. This type of address tracking can be used as a predictor for the next read command during each read. In one example, the predicted address is derived from the payload of a previous read operation. That is, early in a write operation, the address of the next write can be written to the storage device along with the data in the payload of a given write. Later, when that payload is the subject of a read request, its payload can be parsed to obtain the address of the next write address. This next write address can then be used as the next / predicted read address.

[0026] This way, the data at the predicted address can be pre-fetched before any subsequent reads that might target the same address. Data can be buffered before the associated read. If the next read request targets the predicted address, the buffered data can be returned immediately without having to wait for the read operation. If the next read does not target the predicted address, the data can be discarded.

[0027] Obtaining the address of the next write command is possible because, due to the time it takes to program data on the media, there is a high probability that there will be other write commands in the queue when a given write is performed. Conversely, due to the relative speed of reads and writes, there is a low probability that there will be other read requests in the queue. Therefore, predicting the next read is useful because the read queue may be empty during a read.

[0028] In some implementations, power consumption may increase due to enhanced read-ahead because not all predictions will be successful. A countermeasure to reduce redundant overhead and additional power consumption is to track the success rate of the proposed predictions. When the success rate is above a certain threshold, predictive reads can be conditionally enabled, and when the success rate is below the threshold, predictive reads can be disabled.

[0029] In various implementations, the storage device may be, for example, a solid-state drive (SSD), a hard disk drive (HDD), a hybrid SSD-HDD, or any other type of storage device. The device includes a controller that oversees how data is written to and read from a medium such as NAND-based flash memory, dynamic random access memory (DRAM), a magnetic data storage device, an optical data storage device, and / or any other type of storage technology.

[0030] The controller can be implemented in hardware, firmware, software, or a combination thereof and bridges the memory components of the device to the host. In a hardware implementation, the controller includes a control circuit coupled to the storage medium. The control circuit includes a receiving circuit that receives write requests from the host. Each write request includes the data that is the subject of the write request and the target address of the data. The target address can be a logical block address (LBA), a physical block address (PBA), or other such identifier that describes the location of the stored data.

[0031] The control circuitry also includes a position circuit that identifies a next write address for a next write request following an earlier write request. The write circuitry in the control circuitry writes the data for the write request and an indication of the next write address to the target address for the write request. In other words, the data that is the subject of the write request is written to the storage device along with the address of the next write request. As used herein, an "indication" refers to any data value, bit, value, signal, flag, condition, offset, code, or number that identifies or can be used to determine the location of the set of data to be subsequently stored on the medium.

[0032] In a short example, a 16kb page of 4 bytes being written can be used for the address of the next write (0.025% overhead). The address of the next write can be written in the header portion of a given page, but it is also possible to store the address in the user data portion of the page. Examples of addresses include PBA, LBA, or both, as well as any other information indicating the location of the next write. In some embodiments, the next write address is the absolute address of the location where the next data is stored, including die, page, and block information. In other embodiments, the indication of the next write address can be an offset from the current LBA or PBA that can be used to resolve the next address. In other examples, the next address can be written as a shortened version of the address. The address of the next write can be stored in encoded form, unencoded form, or in any other way.

[0033] After a write request, the host may transmit a read request with the same target address as the address in the initial write request. The read circuitry in the control circuitry reads the data and the next write address from the target address. Furthermore, the read circuitry performs a pre-read at the location indicated by the next write address to obtain the next data before the next read request. As described above, the next write address used as the pre-read address may be indicated by an LBA, PBA, offset, flag, etc. For example, if the next write address is stored as a PBA, no conversion is required. For offsets, signals, flags, etc., the control circuitry may calculate the pre-read PBA and values ​​associated with the offset, signal, flag, etc. from the current PBA. Once the host transmits the next read request, the next data is immediately ready to be returned to the host. In some cases, both the initial read request and the next read request are considered random read requests, and therefore the read operation is considered a random read. In some implementations, the control circuitry further includes a buffer circuit to store the indication of the next write address and the next data. The indication of the next write address to be buffered can be stored as a value that can be compared with the target address associated with a subsequent read request. For example, the buffered value can be an LBA, which can be compared to the LBA in a subsequent read request. In certain embodiments, if the subsequent read request utilizes a PBA, the buffered value can be a PBA instead of an LBA. In some cases, the addresses and data associated with multiple pre-read operations can be stored in the buffer simultaneously. The size of the buffer can be set so that it can accommodate one or more pages of data. In one case, the buffer can be 96kB or less of RAM, or the size of about four pages of data. However, it should be understood that the RAM size can be increased and the page size can also be increased.

[0034] The comparator portion of the control circuitry can then determine whether the next target address specified in the next read request matches the next write address. This can be accomplished by comparing the value of the next write address in the buffer with the value of the address in the next read request. For example, the LBA in the next read request can be compared with the LBA in the buffer. In another example, the PBA in the next read request can be compared with the PBA in the buffer. In some alternative embodiments, the value stored in the buffer may differ from the actual value of the next write address stored on the media or calculated during a pre-read operation by an offset. In this case, the control circuitry will first calculate the actual value and then compare it with the value in the next read request. If the values ​​match, the comparator or other components of the control circuitry can return the next data to the host in response to the next read request. If the next target address given in the next read request does not match the next write address, the comparator can discard the next data.

[0035] In some implementations, the controller may include a write queue and a read queue. The read queue receives read requests from the host, while the write queue receives write requests. The read request may indicate a location in the non-volatile storage medium from which data is to be read, thereby allowing the controller to retrieve data from the location indicated by a given read request.

[0036] After this operation, the controller resolves the predicted address of the next read request from the payload that will be read from that location. The controller can then pre-fetch additional data from the predicted location of the next read request before actually receiving the next read request. If the actual location of the next read request is different from the predicted location, the controller can simply discard the next data and continue reading from the actual location.

[0037] With respect to the write queue, each write request in the queue indicates a location at which data is to be written for a given write request. A predictor portion of the controller identifies a predicted location for the next read request based on the location indicated by the next write request following the earlier write request. The write portion of the controller may write the data for the earlier write request and an indication of the predicted location to the location indicated for the earlier write request. A buffer portion of the controller may store the indication of the predicted location for the next read request and the next data.

[0038] As described above, the comparator portion can determine whether the location indicated by the next read request matches the predicted location of the next read request. The comparator or other portion of the controller can return the next data to the host. If the location indicated by the next read request does not match the predicted location of the next read request, the next data can be discarded.

[0039] Such enhanced read-ahead technology provides various technical advantages, which can be seen from the above and below Figures 1 to 10 The discussion is self-explanatory. For example, pre-fetching data in advance of a read request improves read speed. This can be particularly beneficial for random reads, which take longer to complete because data is spread across the media. In another example, the controller does not need to be aware of the requesting application on the host. Instead, the controller can employ enhanced pre-emptive operations without knowledge of the requesting application.

[0040] Now turning to the accompanying drawings, Figure 1 A computing system 100 is shown in a specific implementation of the enhanced read-ahead technique. The computing system 100 includes a host 101 and a storage device 110. The host 101 represents any host subsystem that can write data to and read data from the storage device 110. The storage device 110 represents any device that can be connected to the host 101 internally or externally for reading and writing data. Examples of the storage device 110 include, but are not limited to, solid-state drives (SSDs), thumb drives, hard disk drives (HDDs), hybrid SSD / HDD drives, and any variations or combinations thereof. Examples of the computing system 100 include, but are not limited to, personal computers, laptop computers, server computers, tablet computers, mobile phones, network drives, consumer electronic devices (e.g., cameras, televisions, and media players), gaming devices, durable goods devices, and any other systems, variations, or combinations thereof that utilize one or more storage devices.

[0041] Host 101 communicates with storage device 110 via connector 103. Connector 103 represents one or more physical interconnects that couple host 101 and storage device 110 and through which storage communications can flow between the two. When host 101 communicates with storage device 110, one or more interface protocols may be utilized, such as (but not limited to) Serial ATA (SATA), Fibre Channel, FireWire, Serial Attached Small Computer System Interface (SAS), Advanced Technology Attachment / Integrated Drive Electronics (ATA / IDE), Universal Serial Bus (USB), and Peripheral Component Interconnect Express (PCIe).

[0042] The storage device 110 includes a controller 111 and a storage medium 115. The controller 111 represents one or more processing elements that oversee the writing and reading of data into and from the storage medium 115. The controller 111 is capable of executing a write process 200 and a read process 300, respectively. Figure 2 and Figure 3As described in more detail in

[15] , the write and read processes may be implemented in hardware, firmware, software, or other forms of program instructions executable by controller 111. Storage medium 115 is any non-volatile medium on which data can be written and read. Examples include, but are not limited to, NAND flash media, DRAM media, phase-change media, magnetic media, and optical media. Connector 113 represents one or more physical interconnects that couple controller 111 and storage medium 115.

[0043] In operation, the host 101 transmits read and write requests to the controller 111 for execution on the storage medium 115, where write request 121 and read request 125 are representative. The controller 111 performs a write process 200 when processing the write request 121 and performs a read process 300 when processing the read request 125. The following is a detailed discussion of the write process 200 and the read process 300, and substantially refers to each of the respective Figure 2 and Figure 3 Steps in .

[0044] See also Figure 2 , the controller 111 receives a given write request from the host 101 (step 201). The write request includes the data to be written and a location indicating where on the storage medium 115 the data is to be written. The location may be given by a physical block address (PBA), a logical block address (LBA), or any other suitable indication. In some cases, the location may not be given in the write request itself, but may be provided separately by the host 101 or determined when the write request is received by the controller 111.

[0045] Next, the controller 111 identifies the next location for the next write request submitted by the host 101 (step 203). This can be accomplished by, for example, reading the address associated with the next write request in the write queue. The controller 111 then generates a payload to be written to the location specified for the initial write request (step 205). The payload may include at least the data for the first write request and the next location for the next write request. The next location may be a PBA, but alternatively may be an LBA.

[0046] While only a single next location is included in the payload in this example, it should be understood that multiple locations can be stored in a single payload. For example, both the next address and the next address after it can be stored in a given payload. Furthermore, while the term "next" as used herein refers to the immediately next address in the queue, variations are possible. For example, the immediately next address can be skipped, and instead the next address after the immediately next address can be used and included in the payload.

[0047] After generating the payload, the controller 111 writes the payload to the initial location specified for the write request (step 207). This stores the data for the write request along with an identifier for the location of the next write request in the queue. The write process 200 can continue to obtain subsequent write requests, writing the address of the next write request so that each previous request is accompanied by the data for that request. The subsequent location information can be used as a predicted location for the read process 300, discussed below.

[0048] See also Figure 3 In the read process 300 in FIG. 1 , the controller 111 receives a given read request from the host 101 (step 301). The read request includes the address of the data to be read by the controller 111. The location can be specified as a PBA or an LBA, in which case the controller 111 converts the LBA to a PBA.

[0049] The controller 111 retrieves the payload from the storage medium 115 at the address given by the read request (step 303) and parses the payload into its data and the next location to be stored with the data in the context of the write process 200 (step 305). The data can be returned to the host 101 (step 306), and the next location is used to pre-fetch the next data (step 307).

[0050] It should be understood that the pre-fetch step need not always occur. Conversely, if the payload contains a null value or otherwise does not include a next location, the controller 111 may avoid attempting to pre-fetch data. In another optional example, if the read request is not a random read request, the controller 111 may avoid performing the parsing and pre-fetch steps. That is, before proceeding to steps 305 and 307, the controller 111 may first determine whether the read request is a random read request. The controller 111 may determine that the read request is a random read itself, or may be informed of this fact by the host 101.

[0051] The address of the next location and the pre-fetched data can be buffered so that they are available when a subsequent read request is received. In some implementations, the payload may include more than one next address, in which case the controller may pre-fetch and buffer data from multiple locations. Multiple "next addresses" will then also be buffered.

[0052] The controller 111 can compare the address in a subsequent read request with the next address in the buffer to determine if they are the same (or with multiple subsequent addresses if present in the buffer). If they are the same, the controller 111 can return the pre-fetched data to the host 101 in response to the subsequent read request, rather than having to fetch it.

[0053] Re-reference Figure 1 In the exemplary scenario shown, host 101 submits write requests 121 to storage device 110. Write requests 121 include a first request having data d1 and address L1; a second request including data d2 and location L2; and an nth request including data dn and location Ln.

[0054] Applying write process 200 to the first write request, controller 111 generates payload 123 to be written to storage medium 115. Controller 111 generates payload d1_L2 from the data in the first request and the address in the second request. The payload is written to storage medium 115. Similarly, controller 111 generates payload d2_L3 for the second request. The payload generated for the nth request includes the data from the nth request and the location of the next write request in the queue, or dn_Ln+.

[0055] Host 101 also submits read requests, of which read request 125 is representative. Read request 125 identifies location L1 as representing, for example, a random read request, although other types of reads are possible.

[0056] Applying the read process 300, the controller 111 retrieves (and pre-retrieves) the payload 127 in response to a read request from the host 101. For example, the controller 111 retrieves the payload from location L1, which is the payload of the first write request discussed above, or d1_L2.

[0057] Controller 111 parses the payload to obtain the next location, L2. The data portion (d1) of the payload can be returned to host 101. Before another read request directed to L2, controller 111 also pre-fetches the payload at location L2. This payload is also parsed into its data portion (d2) and location portion (L3).

[0058] Assuming another read request is received directed to L2, the controller 111 can immediately return a response with data d2 without having to fetch the data. However, if no read request is received directed to L2, the data d2 can be discarded or overwritten after a period of time. The controller can optionally pre-fetch the payload at location L3, then pre-fetch the payload again at location Ln+, and so on, until the limit constraint is reached.

[0059] Figure 4An operational scenario 400 is shown in a specific implementation illustrating various timing aspects of the enhanced read-ahead techniques disclosed herein. Operational scenario 400 involves a host 401, a write queue 403, a read queue 404, a controller 405, and a medium 407. Although shown separately, write queue 404 and read queue 404 may be implemented externally or internally relative to controller 405. It should be understood that other elements, connections, etc. may be involved but are not shown for clarity.

[0060] In operation, host 401 transmits two write requests, represented by w1(d1, L1) and w2(d2, L2), to write queue 403. Although shown as direct communication between host 401 and the queue, it should be understood that the requests are routed through other physical or logical elements, including controller 405, before reaching write queue 403.

[0061] Controller 405 implements write requests in the general order in which they are received in the queue. Therefore, controller 405 first implements w1 and then w2. Relative to the first write request, controller 405 checks the queue to identify the address of the next write request (i.e., w2). With L2 known, controller 405 generates a payload for w1 that includes d1 and L2. Controller 405 then writes d1 and L2 to media 407 at the location specified by the first write request L1.

[0062] According to the general order of the queue, controller 405 next processes the second write request. For illustrative purposes, assume that the third write request is after w2 in write queue 403 and is addressed to L3. Therefore, controller 405 generates a payload for w2 that includes d2 and L3. The payload is then written to L2 on media 407.

[0063] Later, after the write is complete, host 401 can submit a read request to obtain the data previously written for w1. Read queue 404 is filled with read requests indicating the address of the data to be obtained. Controller 405 retrieves the payload stored at the indicated address, which includes the data (d1) and the next location (L2).

[0064] Controller 405 parses the payload into its data and location components and returns the data portion to host 401. Using the location portion, controller 405 pre-fetches the payload at location L2. This payload includes the data (d2) and another "next" location (L3). Controller 405 buffers the data with the location (L2) from which it was retrieved, rather than the location where it was stored. Controller 405 may optionally perform another pre-fetch of the payload stored at L3.

[0065] Host 401 transmits a subsequent read request. In response, controller 405 compares the location in the subsequent read request with the location stored in the buffer. In this example, both addresses reflect L2. In this way, controller 405 can answer the read request with buffered data d2 without having to retrieve the data from medium 407.

[0066] Figure 5 A computing system 500 is shown in another embodiment of an enhanced read-ahead technique applied in the context of a multi-threaded environment. The computing system 500 includes a host 501 and a storage device 510. The host 501 represents any multi-threaded subsystem that can write data to and read data from the storage device 510. The storage device 510 represents any device that can be connected to the host 501 internally or externally for reading and writing data.

[0067] Thread 502 and thread 504 each represent various threads available in a multi-threaded environment. Each thread can be dynamically assigned to a different application, utility, or component running in host 501 at runtime. The threads submit read requests represented by request 522 (associated with thread 502) and request 524 (associated with thread 504) to storage device 510.

[0068] Host 501 communicates with storage device 510 via connector 503. Connector 503 represents one or more physical interconnects that communicatively couple host 501 and storage device 510. When host 501 communicates with storage device 510, one or more interface protocols may be utilized, such as, but not limited to, Serial ATA (SATA), Fibre Channel, FireWire, Serial Attached Small Computer System Interface (SAS), Advanced Technology Attachment / Integrated Drive Electronics (ATA / IDE), Universal Serial Bus (USB), and Peripheral Component Interconnect Express (PCIe).

[0069] Storage device 510 includes a controller 511 and a medium 515. Controller 511 represents one or more processing elements that control the reading and writing processes relative to medium 515. Controller 511 can execute a writing process 600 and a reading process 700, respectively. Figure 6 and Figure 7 5. The medium 515 is any non-volatile medium on which data can be written and read. Examples include, but are not limited to, NAND flash media, DRAM media, phase-change media, magnetic media, and optical media. Connector 513 represents one or more interconnects that couple the controller 511 and the medium 515.

[0070] In operation, the host 501 transmits read and write requests to the controller 511. The controller 511 performs a write process 600 when processing a write request and performs a read process 700 when processing a read request. The following is a detailed discussion of the write process 600 and the read process 600, and substantially refers to Figure 6 and Figure 7 Steps in .

[0071] See also Figure 6 , the controller 511 receives a plurality of write requests 2 from the host 501 (step 501). Each write request includes the data to be written and a location indicating where on the medium 515 the data is to be written. The location may be given by a physical block address (PBA), a logical block address (LBA), or any other suitable address. In some cases, the location may not be given in the write request itself, but may be provided separately by the host 501 or determined when the write request is received by the controller 511.

[0072] For any given write request, the controller 511 then identifies the thread associated with the next request (step 603). The thread may be identified in the next write request, or the thread may be determined in some other manner. The controller 511 compares the thread associated with the immediate request with the thread associated with the next request to determine whether they are the same (step 605).

[0073] If the threads are identical, the controller 511 generates a payload consisting of data for the next address of the immediate request and the next write request (step 607). The payload is then written to the indicated address (step 609). However, if the threads are different, the controller 511 simply writes the data to the indicated address (step 606), thereby saving resources by avoiding the step of generating a payload.

[0074] See also Figure 7 , controller 511 receives a read request identifying a target address (step 701). In response, controller 511 checks the pre-read flag to determine if any information has been buffered for a previous read request (step 703). If the flag is enabled, controller 511 evaluates the target address in the request relative to the address stored in the buffer (step 705). If they are the same, the controller can read from the buffer the data that was previously acquired in the context of processing the previous read request (step 706).

[0075] If the addresses are not the same, the controller 511 continues to obtain the payload at the specified address in the read request (step 707). The controller 511 parses the payload into its components, which include at least data and an address related to the next data to be written after the subject data (step 709).

[0076] With the existing data, the controller 511 can read the data out to the host 501 (step 710). The controller 511 also checks whether the next address is empty or some other value indicating that the next address has not been written to the storage device (step 711). This may be the case, for example, when the next write request after a given write request does not originate from the same thread (see above with respect to Figure 6 Step 605).

[0077] If the next address value is null, the controller 511 sets the flag to disabled (step 712), so that the step of comparing addresses can be skipped when a subsequent read request is received. If the next address is not null, the controller 511 sets (or maintains) the flag value to enabled, so that the target address in the subsequent read request can be compared (step 713).

[0078] After setting the flag, the controller 511 pre-fetches the payload stored at the location of the next address parsed from the subject payload (step 715). The controller 511 stores the next data from the pre-fetched payload in the buffer together with the address corresponding to the next data (step 717). When the read process 700 returns to step 705, the next address can be compared with the subsequent target address included in the subsequent read request.

[0079] Figure 8 The operational architecture 800 and associated exemplary scenarios for a specific implementation of the enhanced read-ahead technique on the write side are shown. Figure 8 、 Figure 9A and Figure 9B The operational architecture 900 of a specific implementation of the read side of the enhanced read-ahead technique, and associated exemplary scenarios, is shown. It should be understood that the two architectures can be combined (without any redundant elements) in the context of suitable storage devices (such as SSDs, hybrid HDD / SSDs, etc.).

[0080] See also Figure 8 , the operational architecture 800 includes a write queue 810, a medium 810, and various operational modules represented by a positioning module 801, a receiving module 803, and a write module 805. The positioning module 801, the receiving module 803, and the write module can be implemented in hardware, firmware, or other software, as well as any variations or combinations thereof. The write queue 810 can be implemented externally to the medium 830, but can also be implemented internally. In either case, the write queue 810 can be accessed by one or more of the positioning module 801, the receiving module 803, and the write module 805. It should be understood that the operational architecture 800 may include other elements that have been omitted for clarity, such as a system bus, interfaces, and interconnects.

[0081] In operation, write requests are received from a host (not shown) into a write queue 810 and occupy a sequence or position in the queue. The write requests are represented by request w1 in position 811; request w2 in position 813; request w3 in position 815, and request n in position 817. Thus, the write requests are processed in the following order: w1, w2, w3, wn, etc.

[0082] When a write request is scheduled for execution from the write queue 810, the receive module 803 receives the write request. For example, the receive module 803 receives request w1 and passes it to the write module 805. Request w1 includes data (d1) and a location identifier (L1) at which the data is to be written.

[0083] Position module 801 looks in write queue 810 to identify the location of the next write request in the queue after the subject write request (in this case, w2). The location of w2 is L2, and therefore position module 801 passes L2 to write module 805. Write module 805 receives both the information from receive module 803 and the information from position module and generates a payload to be written to L1. In this example, payload 831 is a combination of d1 and L2.

[0084] Similar operations are performed with respect to other write requests in the queue. Payload 833 is generated in association with w2 and includes data d2 and location L3. Payload 835 is generated in association with w3 and includes data d3 and location L4. Finally, payload 837 is generated in association with wn and includes data dn and location Ln+. In this way, payloads can be inspected during the read process and pre-fetched where appropriate, thereby speeding up the read process.

[0085] See also Figure 9A , the operational architecture 900 includes a read queue 950, a medium 910, and various operational modules represented by a comparison module 941, a read module 943, and a buffer 947. The read module 943 may include a parsing module 945, but it may be implemented externally relative to the read module 943. The comparison module 941, the read module 943, the buffer 947, and the parsing module 945 may be implemented in hardware, firmware, or other software, as well as any variations or combinations thereof. The read queue 910 may be implemented externally to the medium 930, but it may also be implemented internally. In either case, the read queue 910 may be accessed by one or more of the comparison module 941, the read module 943, and the buffer 947. It should be understood that the operational architecture 900 may include other elements that have been omitted for clarity, such as a system bus, interfaces, and interconnects.

[0086] In operation, a read request is received from the host into the read queue 950. The read request is received by Figure 9A r1 in and Figure 9B Requests have an order or position in the queue, represented by position 951, position 953, and position 955, respectively. For ease of explanation, it is assumed that the read requests are random read requests rather than sequential read requests, but sequential read requests can be interspersed among random read requests.

[0087] The read request is removed from the queue and passed to the comparison module 941. The comparison module 941 compares the address in the given read request with the address buffered in the buffer 947 (if any) to determine whether the subject data needs to be retrieved or whether the subject data has already been retrieved. In this example, the read request r1 is associated with location L1. L1 is compared with Lx in the buffer 947. Since they do not match, the comparison module 941 passes the address to the read module 943.

[0088] Read module 943 is responsible for retrieving payload 931 from location L1. Parsing module 945 parses the payload into its component parts d1 and L2. Read module 943 can return d1 to the host and pre-retrieve payload 933 from L2. Payload 933 includes data d2 and location L3. Data d2 is transferred to buffer 947 for storage associated with location L2.

[0089] Figure 9B Shown in Figure 9A A continuation of the exemplary scenario begun in . Figure 9B In the example, comparison module 941 receives read request r2 and removes it from the queue. Here, comparison module 941 determines that the target address in r2 is the same as the address stored in buffer 947. Therefore, comparison module 941 instructs read module 943 to read data d2 from buffer 942 to the host. Read module 943 can be omitted in this step.

[0090] Since the payload at location L2 references the next address L3, the read module may optionally pre-fetch payload 935 at L3. The parsing module will then parse payload 935 to obtain data d3. Data d3 and location L3 will be stored in buffer 947 for comparison with one or more subsequent read requests.

[0091] Figure 10 A power control process 1000 is shown in a specific implementation, whereby the enhanced read-ahead techniques disclosed herein are dynamically enabled and disabled based on various operating conditions. A controller in a solid-state drive or other suitable storage device can employ the power control process 1000, which can be implemented in hardware, firmware, or other software.

[0092] In operation, a given controller tracks the hit rate of read-ahead attempts made in the context of an enhanced read process (step 1001). The hit rate can be related to the ratio of subsequent read requests that actually request pre-fetched data. For example, an initial read request directed to a first location can generate a payload identifying a second location. The data at the second location will then be pre-fetched before any subsequent read request that may (or may not) target the second location. If the next read request is directed to the second location, the pre-fetch will be considered a hit, while if the next read request is directed to a different location, the pre-fetch will be considered a miss.

[0093] The controller may track the success rate of the pre-fetch operation by counting the number of times the pre-fetched data becomes the subject of a subsequent read request. The controller may also analyze whether the hit rate is below a given threshold (step 1003).

[0094] If the hit rate remains equal to or above the threshold, the controller may continue to operate with the read-ahead process enabled.If the hit rate drops below the threshold, the controller disables the read-ahead process (step 1005).

[0095] To re-enable the pre-reading process, the controller periodically evaluates one or more other conditions (step 1006). For example, pre-reading may be disabled for a period of time, after which pre-reading is automatically re-enabled. In another example, pre-reading may remain disabled until the battery level or other power conditions are met. Until then, the controller operates with the pre-reading process disabled.

[0096] Disabling the read-ahead process can save power, reduce processing cycles or other resources in the face of a large number of missed read-ahead attempts. Re-enabling the process when conditions change allows the device to regain the benefits of enhanced read-ahead.

[0097] Physical Description of an Exemplary Operating Context: Data Storage System

[0098] There is a commercial need for a large-capacity digital data storage system in which a plurality of data storage devices (DSDs) (such as solid-state drives (SSDs) and / or hard disk drives (HDDs) and / or hybrid SSD-HDD drives or any other type of storage device or variations or combinations thereof) that can be connected to a host computer 1150 for reading and writing data can be housed in a common housing. The data storage system typically includes a large housing that houses a plurality of shelves on which rows of DSDs are mounted.

[0099] Recall that random read performance is the performance limiting factor for data storage devices and can introduce latency into the read process, impacting the overall performance of the device. Therefore, any method that can predict which address will be read next saves time, which can reduce overall device latency. Therefore, methods that predict which data will be requested next from the controller and initiate a "read-ahead" (or "pre-fetch") can improve random read performance and reduce device latency.

[0100] Figure 11 1 is a block diagram illustrating a simplified computing system architecture according to one embodiment. The exemplary computing system architecture includes a data storage system 1100 comprising a plurality of data storage devices (DSDs) 1104a (DSD1), 1104b (DSD2), and 1104n (DSDn) (collectively, 1104a through 1104n), where n represents any number of DSDs that may vary depending on the specific implementation. Each DSD 1104a through 1104n communicates with a system controller 1102 via a corresponding communication interface 1114 according to a corresponding communication or interface protocol 1115 and is under some level of supervisory control of the system controller. Each DSD 1104a to 1104n includes a corresponding non-volatile memory (NVM) 1106 controlled by a corresponding DSD memory controller 1108, which oversees how data is written to and read from the corresponding NVM 1106 (e.g., typically in the form of NAND flash memory in the case of an SSD and rotating disk media in the case of an HDD).

[0101] The system controller 1102 of the data storage system 1100 includes at least a memory 1110, a processor 1112, and a read queue 1113. The read queue 1113 receives and / or is populated by read requests from the host 1150, wherein the read request may indicate a location in the NVM 1106 from which to obtain or read the requested data (e.g., by a logical block address, or "LBA," or a physical block address, or "PBA"), thereby allowing the corresponding DSD controller 1108 to retrieve the data from the appropriate NVM 1106 memory location indicated by the given read request. Although shown separately internally, the read queue 1113 may be implemented externally or internally relative to the system controller 1102, or may be implemented within the memory 1110. It should be understood that the system controller 1102 may involve other components, connections, etc., but for the sake of clarity, these are not shown here.

[0102] The processes, functions, procedures, actions, method steps, etc. described herein as being performed or executable by the system controller 1102 or the DSD memory controller 1108 may include being performed by executing one or more sequences of instructions stored in one or more memory units and resulting in such performance when the one or more sequences of instructions are executed by one or more processors. The system controller 1102 and the DSD controller 1108 may be implemented in any form and / or combination of software, hardware, and firmware. For example, the system controller 1102 may include an application specific integrated circuit (ASIC) including at least one memory unit (e.g., memory 1110) for storing such instructions (such as firmware as a non-limiting example) and at least one processor (e.g., processor 1112) for executing such instructions, thereby implementing the read-ahead capability described elsewhere herein.

[0103] The data storage system 1100 can be communicatively coupled to a host 1150, which can be embodied in a hardware machine (for non-limiting examples, a computer or hardware server, etc.) on which executable code is executed, or embodied as software instructions executable by one or more processors (for non-limiting examples, a software server such as a storage server, file server, database server, application server, media server, etc.). The host 1150 generally represents a client of the data storage system 1100 and has the ability to make read and write requests (input / output or "IO") to the data storage system 1100. It is noted that the system controller 1102 may also be referred to as a "host" because this term is generally used with reference to any device, such as the DSDs 1104a to 1104n, that makes IO calls to a data storage device or device array. When communicating with the data storage system 1100, the host 1150 may utilize one or more interface protocols such as, but not limited to, Serial ATA (SATA), Fibre Channel, FireWire, Serial Attached Small Computer System Interface (SAS), Advanced Technology Attachment / Integrated Drive Electronics (ATA / IDE), Universal Serial Bus (USB), Peripheral Component Interconnect Express (PCIe), and the like.

[0104] Read prediction using metadata hints based on previous read operations

[0105] Analysis of random read logs reveals numerous recurring patterns. According to one embodiment, one method of "read-ahead" involves saving the next read command address in the metadata of the current read address. According to one embodiment, this metadata update can be performed via a conventional "read-modify-write" operation, which provides for reading a memory location and simultaneously writing a new value thereto as an atomic operation. This read-ahead method typically involves, for each incoming read command, updating the metadata of the previous read command with an indication (e.g., a "hint") of the location (and size) of the current read command. This information can then be used in the future, i.e., when the same read command is received, to pre-fetch future random read commands. Consequently, Quality of Service (QoS) parameters can be significantly improved. Specifically, in the context of command execution latency (e.g., from command arrival to completion issuance), if the hit rate of the read-ahead prediction is high, command execution latency is reduced due to the early reading of the media. Therefore, QoS, such as in the form of command execution latency, is a particularly noteworthy parameter in low queue depth scenarios, such as where the host only sends a few (e.g., up to eight) outstanding commands to the device at a time.

[0106] Figure 12 A block diagram illustrating a method for reducing read time according to one embodiment. For example, such a process may be implemented in a multi-application and / or multi-host memory system environment. The method or operation may be implemented to include two processes: (i) finding or identifying underlying patterns in random read operations and distinguishing between processes, and (ii) predicting and updating data / metadata.

[0107] Figure 12 A read queue 1113 is depicted in which a plurality of host read requests or commands are placed or temporarily stored, awaiting processing. For example, a series of received read requests "read n," "read n+1," through "read n+x" are depicted in the read queue 1113, where n represents the next (i.e., top of the queue) read request for processing, and x represents any number of read requests remaining in the read queue 1113 at any given time. According to one embodiment, iteratively processing the current read request "read n" (labeled as process 1202) involves, at block 1203, identifying the application that initiated the request "read n" (e.g., at Figure 11 1150) to sort the read patterns from the set of read requests processed from the read queue 1113. For example, the controller 1102 ( Figure 11) can maintain a table of active current application IDs, and in response to an incoming read request associated with a given application ID, the controller 1102 monitors the read queue 1113 for the next read request "Read n+1" associated with that application ID. Thus, at block 1204, for each application ID, a corresponding read mode is determined or identified.

[0108] Based on the read pattern identified at block 1204, which does not include any write requests, commands, or patterns according to one embodiment (e.g., because read requests and write requests are generally considered separately in the context of system performance capabilities / metrics), a next read request is predicted at block 1205 (predicting "Read n+1"). Accordingly, at block 1206, an update to metadata 1207 corresponding to the "Read n" read request (including the next storage address corresponding to "Read n+1") is pushed to or stored in NVM 1106 based on the next read request prediction of block 1205. That is, metadata 1207 corresponding to the "Read n" request in NVM 1106 is updated with the next data storage address obtained from the next read request (i.e., the "Read n+1" request). As discussed and according to one embodiment, the "Read n" metadata update is pushed to NVM 1106 at block 1206 using a "read-modify-write" operation, such as in response to processing the "Read n+1" request from read queue 1113 rather than in response to a host write command. Thus, as "extra" write operations are added, a consequent benefit is seen with respect to future read performance. Additionally, according to one embodiment, the next data storage address updated in metadata 1207 corresponding to a "read n" request is a logical address (e.g., LBA) rather than a physical address (e.g., PBA), thereby avoiding the performance impact associated with having to update metadata 1207 in NVM 1106 during garbage collection.

[0109] Therefore, based on the above, whenever the controller 1102 ( Figure 11 ) processes another "read n" read request, a "hint" or prediction of the storage location (e.g., storage address) of the next read request "read n+1" may be obtained from metadata 1207 associated with "read n", and may be obtained from NVM 1106 ( Figure 11) pre-fetches the "Read n+1" data. Therefore, if the prediction based on the read pattern is accurate, the data expected to be "Read n+1" corresponding to the next read request is already available to the controller 1102, without having to execute a responsive read command at this time. According to one embodiment, since the read requests are sorted based on their corresponding application IDs (at block 1203), the metadata 1207 corresponding to "Read n" in the NVM 1106 is updated to include the next storage address "Read n+1" only in response to both "Read n" and "Read n+1" corresponding to the same application ID.

[0110] According to one embodiment, in response to the occurrence of an idle 1208 processing time corresponding to the read queue 1113, "next data" 1209 is obtained from the next storage location of the NVM 1106, which is identified as likely to be correct data from the previous "Read n+1". According to a related embodiment, at block 1210, the next data 1209 of the predicted next read request "Read n+1" (such as the data previously obtained during the idle 1208 time) is placed or stored in a cache buffer 1211 (e.g., which may be implemented within the memory 1110). Therefore, the data corresponding to the next read request "Read n+1" is already available in the cache buffer 1211 without the need to execute a read command in response to receiving the next read request "Read n+1" again, and can therefore be returned directly from the cache buffer 1211 to the host 1150 ( Figure 11 ).

[0111] In terms of implementation architecture, in order to maintain the aforementioned procedures for multiple application IDs, it is preferred to maintain several "tracker" processes or processing threads so that each corresponding tracker can handle its own application ID and corresponding incoming read requests as well as corresponding "pre-read" requests and / or metadata updates.

[0112] Methods for pre-fetching data

[0113] Figure 13 FIG. 1 is a flow chart illustrating a method of pre-acquiring data according to one embodiment. Figure 13 The process or procedure may be implemented as one or more sequences of instructions stored in one or more memory units and which, when executed by one or more processors, cause the process to be performed. For example, one or more sequences of instructions stored in one or more memory units (e.g., Figure 11 The sequence of instructions in the memory 1110 or firmware inherent read-only memory (ROM) when executed by one or more processors (e.g., Figure 11 When executed by the processor 1112 of the system controller 1102, it can execute and / or cause Figure 13 Execution of the process shown.

[0114] At block 1302, a read request is received from a host, wherein the read request includes a corresponding data storage address, and the read request is placed in a read queue. For example, from the host 1150 ( Figure 11 ) will read the request "read n" ( Figure 12 ) received read queue 1113 ( Figures 11 to 12 )middle.

[0115] At block 1304, a next read request is received from the host, wherein the next read request includes the corresponding next data storage address, and the next read request is placed in the read queue. For example, the read request "read n+1" ( Figure 12 ) is received from the host 1150 into the read queue 1113.

[0116] At block 1306, metadata corresponding to the read request in the nonvolatile memory is updated with the next data storage address from the next read request. For example, metadata 1207 corresponding to the read request "Read n" is updated in NVM 1106 with the next data storage address from the next read request "Read n+1."

[0117] At block 1308, in response to receiving a read request again from the host, the next data storage address from the metadata corresponding to the read request is read from the non-volatile memory. For example, in response to receiving a read request "read n" again from the host 1150, the next data storage address from the metadata 1207 ( Figure 12 )'s next data storage address.

[0118] At block 1310, the next data is retrieved from the next data storage address before processing the next read request from the read queue. For example, the next data from the next data storage address read from NVM 1106 at block 1308 is retrieved before processing the next read request from the read queue, i.e., it is expected that the next read request will indeed be the read request "read n+1" as predicted.

[0119] Figure 14 FIG. 1 is a flow chart illustrating a method for pre-fetching data into a read queue according to one embodiment. Figure 13 Same, Figure 14 The process or procedure may be implemented as one or more sequences of instructions stored in one or more memory units and which, when executed by one or more processors, cause the process to be performed. For example, one or more sequences of instructions stored in one or more memory units (e.g., Figure 11The sequence of instructions in the memory 1110 or firmware inherent read-only memory (ROM) when executed by one or more processors (e.g., Figure 11 When executed by the processor 1112 of the system controller 1102, it can execute and / or cause execution Figure 14 The process shown can be understood as Figure 13 Optional continuation and / or enhancement of the process.

[0120] At block 1402, in response to an idle processing time associated with or corresponding to the read queue, next data is retrieved from the next data storage address. For example, before the next read request in the read queue 1113 is the predicted read request "Read n+1," the next data read from the NVM 1106 from the next data storage address is retrieved from the NVM 1106 during the idle time.

[0121] At block 1404, the next data from the next data storage address is placed in the cache buffer. For example, the next data retrieved at block 1402 is stored in the cache buffer 1211 based on the next data storage address from metadata 1207 associated with the read request "read n" (originally from the read request "read n+1").

[0122] At block 1406, in response to receiving a next read request again from the host, the next data is returned to the host from cache buffer 1211. For example, in response to receiving a next read request "Read n+1" again from host 1150, the next data is read from cache buffer 1211 and returned to host 1150.

[0123] Such enhanced read-ahead techniques provide various technical advantages, as will be apparent from the foregoing description and illustrations. For example, pre-fetching data in advance of a predicted next read request improves read speed. This can be particularly advantageous with respect to random reads, which take longer to complete because data is spread across the media in random reads.

[0124] As will be appreciated by those skilled in the art, aspects of the present invention may be embodied as systems, methods, or computer program products. Thus, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be collectively referred to herein as "circuits," "modules," or "systems." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable media, having computer-readable program code embodied thereon.

[0125] The included description and drawings depict specific embodiments to teach those skilled in the art how to make and use the best mode. For the purpose of teaching the inventive principles, some conventional aspects have been simplified or omitted. Those skilled in the art will appreciate variations from these embodiments that fall within the scope of the present disclosure. Those skilled in the art will also appreciate that the above-described features can be combined in various ways to form multiple embodiments. Therefore, the present invention is not limited by the specific embodiments described above, but is limited only by the claims and their equivalents.

Claims

1. An electronic device comprising: non-volatile storage media; Read queue; and a control circuit coupled to the non-volatile storage medium and configured to: receiving a read request from a host, the read request including a corresponding data storage address, and placing the read request in the read queue; receiving a next read request from the host, the next read request including a corresponding next data storage address, and placing the next read request in the read queue; ordering read requests from one or more hosts based on an application identifier corresponding to each of the read requests; In response only to both the read request and the next read request corresponding to the same application identifier, updating metadata corresponding to the read request in the non-volatile storage medium with the next data storage address from the next read request; as well as In response to an idle processing time corresponding to the read queue occurring, next data is acquired from the next data storage address.

2. The electronic device according to claim 1, wherein the control circuit is further configured to: In response to receiving the read request again from the host, reading the next data storage address from the metadata corresponding to the read request from the nonvolatile storage medium; and Before processing the next read request, the next data is obtained from the next data storage address. 3 . The electronic device according to claim 1 , wherein the updating of the metadata corresponding to the read request in the non-volatile storage medium is based on and responds to the next read request and does not include a write request. 4 . The electronic device of claim 1 , wherein the next data storage address updated in the metadata corresponding to the read request is a logical block address (LBA) corresponding to the next read request.

5. The electronic device according to claim 1 , wherein the control circuit is further configured to: The next data from the next data storage address is placed in a cache buffer.

6. The electronic device according to claim 5, wherein the control circuit is further configured to: In response to receiving the next read request again from the host, the next data from the cache buffer is returned to the host.

7. The electronic device according to claim 1, wherein the control circuit is further configured to: Wherein updating the metadata comprises writing the next data storage address to the non-volatile storage medium using a read-modify-write command.

8. The electronic device according to claim 1, wherein the control circuit is further configured to: A respective tracker process corresponding to each different application identifier is executed to update the metadata corresponding to the read request corresponding to each respective application identifier.

9. The electronic device according to claim 1, wherein the electronic device is a data storage device.

10. A method comprising: receiving a read request from a host, the read request including a corresponding data storage address, and placing the read request in a read queue; receiving a next read request from the host, the next read request including a corresponding next data storage address, and placing the next read request in the read queue; ordering read requests from one or more hosts based on an application identifier corresponding to each of the read requests in response only to both the read request and the next read request corresponding to the same application identifier, updating metadata corresponding to the read request in the non-volatile storage device with a logical address corresponding to the next data storage address from the next read request; as well as In response to an idle processing time corresponding to the read queue occurring, next data is acquired from the next data storage address.

11. The method according to claim 10, further comprising: In response to receiving the read request again from the host: reading, from the nonvolatile memory device, the next data storage address from the metadata corresponding to the read request; as well as Before processing the next read request, the next data is obtained from the next data storage address.

12. The method according to claim 10, further comprising: The next data from the next data storage address is placed in a cache buffer.

13. The method according to claim 12, further comprising: In response to receiving the next read request again from the host, the next data from the cache buffer is returned to the host. 14 . The method of claim 10 , wherein the updating the metadata comprises writing the logical address corresponding to the next data storage address to the non-volatile memory device using a read-modify-write command.

15. The method according to claim 10, further comprising: A respective tracker process corresponding to each different application identifier is executed to update the metadata corresponding to the read request corresponding to each respective application identifier.

16. A computing system comprising: means for receiving a read request from a host and for placing the read request in a read queue, the read request including a corresponding data storage address; means for receiving a next read request from the host and for placing the next read request in the read queue, the next read request including a corresponding next data storage address; means for ordering read requests from one or more hosts based on an application identifier corresponding to each of the read requests; means for updating metadata corresponding to the read request in a non-volatile memory with the next data storage address from the next read request in response only to both the read request and the next read request corresponding to the same application identifier; as well as means for performing the following operations in response to receiving the read request again from the host: reading, from the nonvolatile memory, the next data storage address from the metadata corresponding to the read request; as well as In response to an idle processing time corresponding to the read queue occurring, next data is acquired from the next data storage address.

Images