TWI714800B - Solid state drive, non-transitory storage medium and method for operating solid state drive - Google Patents

Abstract

A Solid State Drive (SSD) is disclosed. The SSD may include flash memory to store data and may support a plurality of device streams. A SSD controller may manage reading and writing data to the flash memory, and may store a submission queue and a chunk-to-stream mapper. A flash translation layer may include a receiver to receive a write command, an LBA mapper to map an LBA to a chunk identifier (ID), stream selection logic to select a stream ID based on the chunk ID, a stream ID adder to add the stream ID to the write command, a queuer to place the chunk ID in the submission queue, and background logic to update the chunk-to-stream mapper after the chunk ID is removed from the submission queue.

Description

Solid state drives, non-transitory storage media, and operating solid state drives Dish method

The concept of the present invention is generally related to solid state drives (Solid State Drive; SSD), and more specifically, is about managing streams in a multi-stream SSD.

Multi-stream solid state drives (SSD) allow intelligent placement of incoming data to minimize the impact of internal garbage collection (GC) and reduce write amplification. Multiple streams can be achieved by adding a simple tag (stream ID) to each of the write commands sent from the host to the SSD. Based on this tag, the SSD can group data into comman blocks.

However, in order to utilize a multi-stream device, the application must be aware that the SSD supports multiple streams so that the software source can assign a common stream to data with similar properties (such as data lifetime). Realization of software multi-stream detection requires software modification. However, modifying any software carries the risk of making unexpected changes to the operation of the software. Knowing that there are a very large number of different software products on the market, it is expected that even if a few of these software products are modified to support multiple streams, it seems an unlikely proposition at best.

There is still a need to support multiple streams without modifying the software.

Considering the above problems, the present invention provides a solid state drive (SSD), which includes: flash memory for storing data; support for streaming of multiple devices in the SSD; and an SSD controller for managing responses Write data to the flash memory in multiple write commands. The SSD controller includes a storage for submitting queues and chunks to a stream mapper; and a flash translation layer. The flash translation layer includes: a receiver for receiving a write command including a logical block address (LBA); an LBA mapper for mapping the LBA to a block identifier (ID ); Stream selection logic to use the block-to-stream mapper to select a stream ID based on the block ID; Stream ID adder to add the stream ID to the Write command; a queuer to place the block ID in the commit queue; and background logic to remove the block ID from the commit queue and update the area Block-to-stream mapper.

105: Machine

110: processor

115: memory

120: Solid State Drive (SSD)

125: Memory Controller

130: device driver

205: Clock

210: network connector

215: Bus

220: User Interface

225: input/output engine

305: host interface logic

310: SSD controller

315-1, 315-2, 315-3, 315-4, 315-5, 315-6, 315-7, 315-8: Flash memory chip

320-1, 320-2, 320-3, 320-4: channels

325: Flash Translation Layer

330: Storage

335: Submit Queue

340: block to stream mapper

405: receiver

410: Logical Block Address (LBA) Mapper

415: Stream selection logic

420: Stream ID Adder

425: Transmitter

430: Queue

435: background logic

505-1, 505-2, 505-3: write command

510-1, 510-2, 510-3: LBA

515-1, 515-2, 515-3, 515-4: block identifier (ID)

520: Arithmetic Logic Unit (ALU)

525: address mask

530-1, 530-2, 530-3, 530-4, 1035: Streaming identifier (ID)

705: block size

805: Sequence, frequency, recency (SFR) table

810-1, 810-2, 810-3, 810-4: current access time

815-1, 815-2, 815-3, 815-4: previous access time

820-1, 820-2, 820-3, 820-4: Access count

905: sequential logic

910: Recency logic

915: Access count adjuster

920: Streaming ID adjuster

1005: storage

1010: Comparator

1015: Windows

1020-1, 1020-2, 1020-3, 1020-4, 1020-5, 1020-6, 1020-7, 1020-8: input items

1025: Queue

1030: End logical block address

1040: Window size

1105: recency weight

1110: Decay period

1205: Adjusted access count

1405-1, 1405-2, 1405-3: Node

1410: Expiry time

1505: boost logic

1510: Second Queue

1515: Storage

1520-1, 1520-2, 1520-3: Queue

1525: downgrade logic

1605: Top of the submission queue

1610, 1615, 1630: dotted arrow

1620: Queue entry

1625-1, 1625-2, 1625-3: the top of the queue

1705: Incrementer

1710: Streaming ID adjuster

1715: Block expiry logic

1720: Hottest block logic

1905: Device life

2005: Comparator

2010: Decreaser

2105, 2110, 2115, 2120, 2125, 2130, 2135, 2140, 2145, 2205, 2210, 2305, 2310, 2315, 2320, 2325, 2330, 2335, 2405, 2410, 2415, 2420, 2505, 2510, 2515, 2520, 2525, 2530, 2535, 2540, 2545, 2550, 2555, 2560, 2565: block

FIG. 1 illustrates a machine with a solid state drive (SSD) according to an embodiment of the inventive concept.

Figure 2 shows additional details of the machine of Figure 1.

FIG. 3 shows the details of the SSD of FIG. 1.

FIG. 4 shows the details of the flash translation layer of FIG. 3.

Figure 5 shows the logical block address (LBA) of various commands mapped to the block identification The ID is then mapped to the stream ID for use by the SSD in Figure 1.

FIG. 6 shows that various commands of FIG. 5 are modified to include the stream ID of FIG. 5 and transmitted to the SSD of FIG. 1.

FIG. 7 shows the arithmetic logic unit (ALU) mapping the LBA of FIG. 5 to the block ID of FIG. 5.

FIG. 8 illustrates a sequence, frequency, and recency (Sequential, Frequency, Recency; SFR) table that can be used to map block IDs to stream IDs according to the first embodiment of the inventive concept.

FIG. 9 illustrates additional details of the flash translation layer of FIG. 3 and the background logic of FIG. 4 according to the first embodiment of the inventive concept.

FIG. 10 shows the details of the sequential logic of FIG. 9.

Fig. 11 shows the recency logic of Fig. 9 used to calculate recency weights.

FIG. 12 illustrates the use of the recency weight of FIG. 11 in the access count adjuster of FIG. 9 to adjust the access count.

FIG. 13 illustrates the use of the stream ID adjuster of FIG. 9 to calculate the stream ID according to the adjusted access count of FIG. 12.

FIG. 14 illustrates a node that can be used to map a block ID to a stream ID according to a second embodiment of the inventive concept.

FIG. 15 illustrates the details of the background logic of FIG. 4 according to the second embodiment of the inventive concept.

FIG. 16 shows the promotion and demotion of the block ID in the queue of FIG. 15.

FIG. 17 shows the details of the lifting logic of FIG. 15.

FIG. 18 illustrates the calculation of the stream ID according to the adjusted access count according to the second embodiment of the inventive concept.

FIG. 19 shows the details of the block expiration logic of FIG. 17.

FIG. 20 shows the details of the downgrade logic of FIG. 15.

21A to 21B show a flowchart of the example program of FIG. 5 for determining a stream ID used for a write command according to an embodiment of the inventive concept.

FIG. 22 illustrates a flowchart of an example program of the LBA mapper of FIG. 4 for mapping the LBA of FIG. 5 to the block ID of FIG. 5 according to an embodiment of the inventive concept.

FIGS. 23A to 23B illustrate a flowchart of an example program for updating the stream ID for a block using sequential logic according to the first embodiment of the inventive concept.

FIG. 24 illustrates a flowchart of an example program for performing background update of the SFR table of FIG. 8 according to the first embodiment of the inventive concept.

25A to 25C show a flowchart of an example program for performing background update of the node in FIG. 14 according to a second embodiment of the inventive concept.

Reference will now be made in detail to the embodiments of the concept of the present invention, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth to enable a thorough understanding of the concept of the present invention. However, it should be understood that those skilled in the art can practice the concept of the present invention without these specific details. In other cases, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure the aspect of the embodiments.

It should be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, the first module may be called the second module, and similarly, the second module may be called the first module without departing from the scope of the concept of the present invention. Domain.

The terms used in the description of the inventive concept herein are only for the purpose of describing specific embodiments and are not intended to limit the inventive concept. As for the concept of the invention And used in the description of the scope of the attached application, the singular forms "one" and "the said" It is also intended to include the plural form, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It should be further understood that the term "including" when used in this specification specifies the existence of the stated features, integers, steps, operations, elements and/or components, but does not exclude one or more other features, integers, steps, operations , The existence or addition of elements, components and/or groups thereof. The components and features of the diagram are not necessarily drawn to scale.

A device and method for performing automatic stream detection and designation independent of the application layer are proposed. Streaming designation can be based on running workload detection and can be independent of the application. Streaming designation can be applied to solid state drives (SSDs) with multi-streaming capabilities.

The implementation of the streaming designation protocol has several advantages. First, the application does not need to be modified at all. However, an application that specifies its own streaming priority can be considered in the method. For example, the stream designation protocol can completely comply with the stream priority designated by the application. Alternatively, the stream designation protocol can use any desired weight value to perform a combination of the stream priority designated by the application program and the weighted sum of the calculated stream designation.

Second, any application that uses a device with multi-streaming capabilities can use automatic stream detection and designation. Third, the application does not need to know the streaming-related information from the hardware. Fourth, the streaming designation protocol can individually manage each SSD with multi-streaming capabilities, so that applications can use multiple SSDs, and even mix SSDs with multi-streaming capabilities and SSDs without multi-streaming capabilities. Fifth, string Stream designation can be performed at any desired layer of the system (such as in the file system, in the block layer, in the device drive, in the SSD (for example, in the flash translation layer), etc.), as long as the write can be recognized The start address of the import command (or file offset, in the case that the stream specification protocol is implemented in the file system layer).

The entire address space of the SSD can be divided into several fixed-size chunks. The block size can be any desired size: for example, a multiple of a 512-byte sector. By dividing the LBA by the number of sectors in each block, or more generally, by the block size, the requested starting logical block address (starting LBA) can be converted into a block identifier (ID) .

In the first embodiment of the inventive concept, the sequence, frequency, and recency (SFR) method can be used to determine the stream designation:

●Sequence: If the start LBA of the new request is adjacent to the end LBA of the previous request (ie, the write command involves sequential write), the second write command can be assigned the same stream ID as the earlier write command . This method assumes that a group of sequential requests have a similar life span, when the requests are issued within a short period of time. Since write commands can be issued by different sources (applications, file systems, virtual machines, etc.) and can be mixed with each other, from the perspective of SSD, write commands may not follow a strict sequential pattern. Considering this possibility, the order can be determined with respect to several previous commands in the window (the size of which can be changed). For example, the window size four will check whether the incoming request continues any of the previous four requests.

●Frequency: Frequency refers to the number of times the initial LBA has been accessed. Frequency can be measured as access count. As long as a block is accessed (written), the access count of the block is incremented by one. A higher access count indicates the shorter life of the block. The frequency therefore reflects the temperature of the data chunk.

●Recency: The recency indicates the temporal locality of the data block. For example, a block may be accessed more frequently and accumulate a high access count in a certain period of time, but will be disabled afterwards. In this case, there is no need to keep the block in the hot stream for a long time. A block is considered hot only when it has been frequently accessed in the most recent time period. In an embodiment of the inventive concept, the decay period can be predefined for all blocks. If the block has not been accessed in the last N decay periods, the access count will be divided by 2 ^N.

The stream ID for a block can be determined by both frequency and recency (and sequence, if applicable). If a block is accessed frequently, the frequency will boost the block to a hotter stream, and if the block is disabled during the last decay period, the recency will downgrade the block to a colder stream. In an embodiment of the inventive concept, the logarithmic scale can be used to convert the access count to the stream ID, which can reflect the fact that the number of device streams is much smaller than the value range of the access count. So, for example: recency weight=2 ^{((current time-last access time)/decay period)}

Stream ID=log (access count/recency weight)

The update of the stream ID of the block can be performed as a background task, thereby minimizing the impact on input/output (I/O) performance.

In the second embodiment of the inventive concept, a multi-queue method can be used. For each device stream, a queue can be defined: since there are multiple device streams, there will be multiple queues. The multi-queue algorithm can be divided into two different functional modules. One module is responsible for elevating each block from the lower queue to the higher queue; the other module handles the degrading of the enabled or disabled block from the higher queue to the lower queue. The higher the access count of a block, the hotter the block is considered, and therefore the block is placed in a higher queue. Both promotion and demotion can be performed as background tasks, thereby reducing the impact on I/O performance To the smallest.

When the block is accessed for the first time, it is assigned to stream 0 (lowest stream) and placed in the corresponding queue. Otherwise, the block is removed from the current queue, the access count of the block is updated, and the block is placed in the (potentially) new queue. Any method can be used to determine the appropriate queue based on the access count: for example, the logarithm of the access count can be calculated as the new stream ID (its identification corresponds to the queue). The promotion module can also check to see if the block is currently the hottest block (based on the access count). If it is currently the hottest block, the device lifetime can be set based on the interval between accesses of this block. Finally, the promotion logic can determine the expiration time of the block based on the device lifetime and the last access time of the block.

In order to degrade a block, the downgrade module checks the block when it reaches the top of its queue. If the expiration time of the block has not passed, the block can be left. Otherwise, the block can be removed from its current queue, specify a new expiration time, and downgrade to a lower queue (ie, specify a lower stream ID).

In addition, if the degraded block is the hottest block, the block has not been accessed for a period of time (as determined by the expiry time). Therefore, the block is no longer hot, and another block from the queue can be selected as the hottest block (with an appropriate branch regarding the life of the device). The newly selected hottest block may be the next block in the queue, or it may be the last block to enter the queue.

FIG. 1 illustrates a machine with a solid state drive (SSD) according to an embodiment of the inventive concept. In Figure 1, the machine 105 is shown. The machine 105 can be any desired machine, including (but not limited to) a desktop or laptop computer, a server (standalone server or rack server), or any other device that can benefit from embodiments of the inventive concept . The machine 105 can also include specialized portable computing devices, tablets, and smart phones. Words and other computing devices. The machine 105 can execute any desired application program: the database application program is a good example, but the embodiment of the inventive concept can be extended to any desired application program.

The machine 105 (regardless of its specific form) may include a processor 110, a memory 115, and a solid state drive (SSD) 120. The processor 110 may be any type of processor: for example, Intel Xeon, Celeron, Itanium, or Atom processor, AMD Opteron processor, ARM processor, etc. Although Figure 1 shows a single processor, the machine 105 may include any number of processors. The memory 115 may be any kind of memory, such as flash memory, static random access memory (Static Random Access Memory; SRAM), persistent random access memory (Persistent Random Access Memory), and ferroelectric random access memory. Take memory (Ferroelectric Random Access Memory; FRAM) or non-volatile random access memory (Non-Volatile Random Access Memory; NVRAM) (such as magnetoresistive random access memory (Magnetoresistive Random Access Memory; MRAM)), etc. , But it is usually DRAM. The memory 115 can also be any desired combination of different memory types. The memory 115 can be controlled by the memory controller 125 which is also part of the machine 105.

The SSD 120 can be any type of SSD, and can even be extended to include other types of storage that perform waste item collection (even when flash memory is not used). The SSD 120 can be controlled by the device driver 130 (which can reside in the memory 115).

FIG. 2 shows additional details of the machine 105 of FIG. 1. Referring to FIG. 2, in general, a machine 105 includes one or more processors 110, and the processor may include a memory controller 125 and a clock 205, and the clock may be used to coordinate the operation of the components of the machine 105. The processor 110 may also be coupled to a memory 115. As an example, the memory may include random access memory (RAM), read-only memory (ROM), or other state retention media. The processor 110 may also be coupled to the solid state drive 120 and to the network connector 210, which may be, for example, an Ethernet connector or a wireless connector. The processor 110 can also be connected to the bus 215 to which the user interface 220 and the input/output interface ports that can be managed using the input/output engine 225 and other components can be attached to the bus.

FIG. 3 shows the details of the SSD 120 in FIG. 1. In FIG. 3, the SSD 120 may include a host interface logic 305, an SSD controller 310, and various flash memory chips 315-1 to 315-8, and the flash memory chips may be organized into various channels 320-1 to 320 -4. The host interface logic 305 can manage the communication between the SSD 120 and the machine 105 of FIG. 1. The SSD controller 310 can manage the read and write operations on the flash memory chips 315-1 to 315-8 and the discarded item collection operations. The SSD controller 310 may include a flash translation layer 325 to perform some of this management. In an embodiment of the inventive concept that makes the SSD 120 responsible for assigning a write command to a stream, the SSD controller 310 may include a storage 330 to support stream assignment. The storage 330 may include a submission queue 335 and a block-to-stream mapper 340. The submission queue 335 can be used to store information about blocks affected by various write commands. When a write command is received, the blocks associated with the write commands (or actually, the identifiers (ID) of these blocks) can be placed in the commit queue 335. Then, as part of the background processing procedure (which is used to minimize the impact on the foreground operation), blocks can be removed from the submission queue 335, and the stream assignments for these blocks can be updated. The block-to-stream mapper 340 can store information about which stream is currently assigned to various blocks: as a result of the block ID in the submission queue 335, this information can be updated (or the submission queue There is no block ID in 335-blocks not in use can be assigned to lower priority streams because they are not in use). The concept of blocks will be further discussed with reference to Figure 5 and Figure 7 below.

Although FIG. 3 illustrates the SSD 120 as including eight flash memory chips 315-1 to 315-8 organized into four channels 320-1 to 320-4, the embodiment of the inventive concept can support the organization into any Any number of flash memory chips of number of channels.

FIG. 4 shows the details of the flash translation layer 325 of FIG. 3. In FIG. 4, the flash translation layer 325 is shown as including a receiver 405, a logical block address (LBA) mapper 410, a stream selection logic 415, a stream ID adder 420, a transmitter 425, and a queue Lister 430 and background logic 435. The receiver 405 can receive write commands from various software sources (such as operating systems, applications, file systems, remote machines, and other such sources). For a given write command, the LBA mapper 410 can map the LBA used in the write command to a specific block on the SSD 120 of FIG. 1. The stream selection logic 415 then selects a stream suitable for the block. The stream selection logic 415 may use the block-to-stream mapper 340 of FIG. 3 to complete the stream selection, and may include searching for the block-to-stream mapper 340 of FIG. 3 to find the corresponding block to the selected block. The logic of the entry. Alternatively, the stream selection logic 415 can use other methods: for example, by calculating the stream ID based on the access count of the block (similar to the operation described below with reference to FIG. 13), or by using a round-robin method. Specify the stream (so that write commands are evenly distributed among all device streams). The stream ID adder 420 can then add the selected stream ID to the write command using the logic used to write data to the write command. Once the stream ID has been attached to the write command, the transmitter 425 can transmit the write command (with the additional stream ID) to the SSD 120 of FIG. 1 for execution.

The queuer 430 can obtain the identified block ID for the write command, and can add the block ID to the commit queue 335 of FIG. 3. The queuer 430 can use the logic to add the block ID to the commit queue 335 of FIG. 3. For example, the queuer 430 may include a pointer to the end of the submission queue 335 of FIG. 3, and may write the block ID to the end of the submission queue 335 of FIG. 3, and thereafter, it may be updated to The indicator at the end of the submission queue 335 in FIG. 3 thus points to the next slot in the submission queue 335 in FIG. 3. Finally, the block ID will exit the queue from the submission queue 335 in FIG. 3, and after that, the background logic 435 may perform operations on the block ID that exits the queue. The background logic 435 will be further discussed with reference to FIGS. 9 and 15 below.

The background logic 435 can be implemented in any desired way. For example, the background logic 435 can simply operate to increment the block each time the block is accessed (the operation almost involves the logic used to perform a lookup in the data structure storing the block ID and stream ID and An incrementer used to increment the stream ID thus positioned). However, this simple implementation will mean that, eventually, each block can use the highest numbered stream, while the lower numbered stream is not used. For more implementation, consider whether the block is not commonly used and the streaming priority of the block can be reduced to match. Two embodiments of the inventive concept that implement the background logic 435 in different ways to achieve this result will be described below with reference to FIGS. 8-13 and 14-20.

Although the background logic 435 is described as operating in the "background" (hence the name), performing stream-specific updates in the background facilitates minimizing the impact on reading and writing to the SSD 120 of FIG. Assuming that the stream designation can be updated without affecting the performance of the SSD 120 in FIG. 1, there is no reason why the background logic 435 cannot operate in the "foreground". For example, if the SSD 120 in FIG. 1 includes a processor (that is, the SSD 120 in FIG. 1 provides In-Storage Computing (ISC)), then the SSD 120 in FIG. 1 This processor in the SSD 120 may potentially be dedicated to updating stream assignments in real time without affecting the read and write performance of the SSD 120 in FIG. 1. In this case, the background logic 435 can operate immediately to perform stream-specific updates without placing the block ID in the commit queue 335 of FIG. 3 or waiting until the time when the background logic 435 can operate without affecting the foreground operation.

In FIG. 4, the flash translation layer 325 is shown as responsible for performing stream designation and stream ID update. However, in other embodiments of the inventive concept, one or more of the components shown in FIG. 4 may be implemented by software and may be included as, for example, the memory controller 125 of FIG. 1 and the device of FIG. 1 Part of the drive 130 may be implemented as library routines that can intercept write requests and combine streams before issuing write commands, or implemented as a separate dedicated hardware (in SSD 120 in FIG. 1, or Elsewhere in machine 105). For this discussion, any reference specified to the stream performed by the components of FIG. 4 is intended to encompass implementation at any particular location, even if the description accompanying FIGS. 4-20 focuses on implementation within the flash translation layer 325.

Although FIG. 4 shows the LBA mapper 410 and the stream selection logic 415 as separate components, logically, the structure of these components can be combined into a single component. More generally, the embodiments of the inventive concept can combine any components shown and described in FIGS. 4-6, 9-13, and 15-20 as a single unit into an integral component.

FIG. 5 shows that the logical block address (LBA) of various commands is mapped to a block identifier (ID) and then to a stream ID for use by the SSD of FIG. 1. In FIG. 5, write commands 505-1, 505-2, and 505-3 are shown, but embodiments of the inventive concept can support any number of write commands. In addition, although FIG. 5 only shows the write command, the embodiment of the inventive concept can also be applied to the read command. The write commands 505-1 to 505-3 may include LBA 510-1 to 510-3, which specify the write command Let the starting LBA of 505-1 to 505-3.

The LBA mapper 410 can access the LBA 510-1 to 510-3 from the write commands 505-1 to 505-3. Once the LBA 510-1 to 510-3 have been read from the write commands 505-1 to 505-3, the LBA mapper 410 can determine the corresponding block IDs 515-1 to 515-3. A block can be regarded as a logical sub-division of the SSD 120 (but the block does not need to be aligned with other logical sub-divisions of the SSD 120 (such as block and page)). The number of blocks can be determined in any desired way: for example, by selecting the desired size for the block and dividing the size of the SSD 120 by the block size, or by selecting that has proven to provide sufficient utility without the need for the background of Figure 4 The logic 435 performs an excessive number of processes (and divides the SSD 120 into so many blocks). The blocks need not have the same size, but the uniformity of the size can simplify the operation of the LBA mapper 410. Therefore, for example, one block may include 128 KB of data in SSD 120, and another block may include 512 KB of data in SSD 120. A block size that is a power of two is particularly advantageous because the decision block from the LBA can be performed using a shift operation, but the embodiment of the inventive concept can support any block of any desired size.

The LBA mapper 410 can determine the block IDs 515-1 to 515-3 in any number of ways. For example, the LBA mapper 410 may include an arithmetic logic unit (ALU) 520 for mathematically calculating the block IDs 515-1 to 515-3 according to the LBAs 510-1 to 510-3. Alternatively, the LBA mapper 410 may include an address mask 525, which may mask various bits from the LBA 510-1 to 510-3, thereby leaving the block IDs 515-1 to 515-3.

Once the block IDs 515-1 to 515-3 have been determined, the stream selection logic 415 can determine the stream to be used for the block. The stream selection logic 415 can use the block IDs 515-1 to 515-3 to determine the corresponding stream ID from the block to the stream mapper 340 530-1 to 530-3.

6 shows that the commands 505-1 and 505-2 of FIG. 5 are modified to include the stream IDs 530-1 and 530-2 of FIG. 5 and transmitted to the SSD 120 of FIG. 1. (Due to space reasons, Figure 6 only shows two of the three write commands and associated data from Figure 5. However, Figure 6 is summarized in the same way as Figure 5.) In Figure 6, streaming The ID adder 420 can write the stream IDs 530-1 and 530-2 into the write commands 505-1 and 505-2. In this way, the SSD 120 of FIG. 1 can know which device will be used to stream when processing the write commands 505-1 and 505-2. The transmitter 425 may transmit the modified write commands 505-1 and 505-2 to the SSD 120 of FIG. 1.

The operation of the queuer 430 of FIG. 4 is not shown in FIGS. 5 to 6. Once the block IDs 515-1 to 515-3 of FIG. 5 have been determined, the queuer 430 of FIG. 4 can queue the block IDs 515-1 to 515-3 of FIG. 5 in the submission queue 335 of FIG. 3 , For the background logic 435 of FIG. 4 to process later. The queuer 430 of FIG. 4 can queue the block IDs 515-1 to 515-3 of FIG. 5 at any time after the block IDs 515-1 to 515-3 of FIG. 5 have been determined. For example, after the block IDs 515-1 to 515-3 of FIG. 5 have been determined by the LBA mapper 410 of FIG. 4, the modified write commands 505-1 to 505-3 have been sent to the graph by the transmitter 425. After the SSD 120 of 1 or at any time in between, the queuer 430 of FIG. 4 can queue the block IDs 515-1 to 515-3 of FIG. 5.

FIG. 7 shows that the arithmetic logic unit (ALU) 520 of FIG. 5 maps the LBA 510-1 of FIG. 5 to the block ID 515-1 of FIG. 5. In FIG. 7, ALU 520 can receive LBA 510-1 and block size 705. By dividing the LBA 510-1 by the block size 705 (and discarding any fractional part of the calculation), the block ID 515-1 can be calculated.

As described above with reference to FIG. 4, the background logic 435 of FIG. 4 can be implemented in various ways. Figures 8 to 13 describe an embodiment of the concept of the present invention, and Figure 14 To FIG. 20, another embodiment of the inventive concept is described. These embodiments of the inventive concept are not intended to be mutually exclusive: a combination of two embodiments of the inventive concept is possible. In addition, other embodiments of the inventive concept are also possible, regardless of whether they are explicitly described herein.

In the first embodiment of the inventive concept for the background logic 435 of FIG. 4, the block-to-stream mapper 340 of FIG. 3 may include a sequence, frequency, and recency (SFR) table. "Sequence, frequency, recency" refers to methods that can be used to determine and update the stream ID to be assigned to a block. "Sequence" refers to a situation where one write command is followed by another write command, that is, the second write command writes data to the next LBA after the earlier write command. In the case of two write command sequences, it is reasonable that the two commands should be assigned to the same stream ID.

As described below with reference to FIG. 10, "sequence" should not be understood completely literally in this context, because the write command can be issued from any number of different software sources. If two "sequential" write commands from a single software source (for example, a database application) happen to be separated by a write command from some other software source (for example, a file system), the intervening write command should not be eliminated The sequence of the two write commands from the database application. In fact, this article provides a mechanism to prevent intervening write commands from blocking sequentiality.

"Frequency" refers to how often the block is accessed. The more frequently the block is accessed, the block is considered to be "hotter" (the analogy of the temperature as the priority: the higher the "temperature" of the block, the higher the priority of the block). Therefore, as more and more blocks are accessed, the blocks should be assigned a higher streaming priority.

"Recency" refers to how long a block has passed since it was last accessed. "Recency" acts as a balance of "frequency": the span of the block since the last access Longer, the block is considered to be "colder", and therefore, the block should be assigned a lower priority. Therefore, although the "frequency" increases the associated stream of the block, the "recency" reduces the associated stream of the block. "Sequence", "frequency" and "recency" will be further discussed with reference to Figure 10 to Figure 13 below.

Turning now to the embodiment of the inventive concept shown in FIG. 8, FIG. 8 illustrates an example SFR table according to this embodiment of the inventive concept, which can be used to combine the block IDs 515-1 to 515- of FIG. 3 is mapped to stream IDs 530-1 to 530-3 in FIG. 5. In Figure 8, the SFR table 805 can store various data. For example, the SFR table 805 can store various block IDs 515-1 to 515-4, and SFR corresponding stream IDs 530-1 to 530-4 for each block ID 515-1 to 515-4.

In addition to stream ID 530-1 to 530-4, SFR table 805 can also store additional data. For example, for each block ID 515-1 to 515-4, the SFR table 805 can store the current (ie, most recent) access time of the block 810-1 to 810-4. The current access time 810-1 to 810-4 may be the last access of any type (for example, read or write) of the block, or only the time of the most recent write command. The SFR table 805 can also store previous access times 815-1 to 815-4, which can indicate the time when the block was previously accessed. Finally, the SFR table 805 can store access counts 820-1 to 820-4, which can indicate the number of accesses to the block. As described above, the access counts 820-1 to 820-4 may represent the total number of block accesses (both read and write) or only block write access.

Although FIG. 8 illustrates a possible embodiment of the inventive concept, other embodiments of the inventive concept may store more or less data than shown in FIG. 8. In addition, data structures other than tables can be used to store information. The embodiments of the inventive concept are intended to cover all such variations.

Figure 9 illustrates the flash translation of Figure 3 according to the first embodiment of the inventive concept Additional details of layer 325 and background logic 435 of FIG. 4. In FIG. 9, the flash translation layer 325 may also include sequential logic 905. In order to use the same stream designation as the earlier write command, the sequential logic 905 can determine whether the write command 505-1 of FIG. 5 is followed by an earlier write command. The sequential logic 905 will be further discussed with reference to Figure 10 below.

The background logic 435 may include the recency logic 910, the access count adjuster 915, and the stream ID adjuster 920. The recency logic 910 may calculate the recency weight of the block. The access count adjuster 915 may adjust the access count for the stream based on the recency weight. And the stream ID adjuster 920 may calculate a new stream ID to be used for the block based on the adjusted access count. The recency logic 910, the access count adjuster 915, and the stream ID adjuster 920 can all be implemented using one (or more) separate or shared ALUs because the aforementioned components perform arithmetic calculations. Alternatively, the recency logic 910, the access count adjuster 915, and the stream ID adjuster 920 may be implemented using dedicated hardware designed to calculate only the specific function described and nothing more.

FIG. 10 shows the details of the sequential logic 905 of FIG. 9. In FIG. 10, the sequential logic 905 is shown as including a storage 1005 and a comparator 1010. For practical purposes, the storage 1005 may be part of the storage 330 in FIG. 3 instead of a separate storage in the sequential logic 905. The storage 1005 may store a window 1015, which is information about a set of newly written commands, each of which may have a stream ID assigned to it. For example, FIG. 10 shows the input items 1020-1 to 1020-8, wherein the input items 1020-1 to 1020-4 are in the window 1015. Input items 1020-1 to 1020-8 can be managed in the queue 1025. The queue 1025 can take any desired form: for example, two example implementations, an array with indicators to the top of the queue 1025, or a linked list. Each entry 1020-1 to 1020-8 can contain Write the end of the command LBA 1030 and stream ID 1035 early. The window 1015 may include a window size 1040, which can specify how many recent input items are included in the window 1015: in FIG. 10, the window size 1040 is shown as including four input items, but the embodiment of the inventive concept can support windows Any number of entries in 1015. The window size 1040 may depend on several factors, including, for example, the number of cores in the processor 110 of FIG. 1, or the software source (operating system, file) that can issue write commands executed on the processor 110 of FIG. The number of systems, applications and the like). Embodiments of the inventive concept can also support window sizes determined based on other factors. In addition, the window size 1040 may be statically set, or may be dynamically changed as the conditions in the machine 105 of FIG. 1 change.

When receiving the new write command 505-1 of FIG. 5, the comparator 1010 can compare the LBA 510-1 of FIG. 5 with the end LBA 1030 of the input items 1020-1 to 1020-4 in the window 1015. If LBA 510-1 in FIG. 5 is the next address after the end LBA 1030 of the earlier write command, then LBA 510-1 in FIG. 5 can be regarded as the end LBA 1030 following the earlier write command. Alternatively, if there is no available enabling LBA between the end LBA 1030 of the earlier write command and the LBA 510-1 of FIG. 5, the LBA 510-1 of FIG. 5 can be regarded as a continuation of the earlier write command. End of LBA 1030. (Please note that the ending LBA 1030 does not have to be literally the last address written to by the earlier write command. The condition is that there is no possible intervention address to which data may have been written.) If the one in Figure 5 LBA 510-1 is connected to the end of any entry 1020-1 to 1020-4 in the window 1015. LBA 1030, then the stream ID 1035 in the entry 1020-1 to 1020-4 is used for the write command 505- in Figure 5 1.

Although recognizing sequential LBA is a method to determine when sequentiality occurs, embodiments of the inventive concept can support other implementations to detect sequentiality. For example In other words, the sequential logic 905 can use a pattern matcher to detect when to access the LBA for a specific software source in a repeating pattern.

Regardless of whether the LBA 510-1 in Figure 5 continues any entry 1020-1 to the end of 1020-4 in the window 1015 LBA 1030, the oldest entry in the window 1015 can be "pushed out" and the entry in Figure 5 can be written Command 505-1 was added to Windows 1015. For example, assume that the input item 1020-1 is the input item for the most recently written command in the window 1015, and the input item 1020-4 is the oldest input item in the window 1015. The input item 1020-4 can be removed from the window 1015, and both the LBA 510-1 and the stream ID 530-1 of FIG. 5 can be added to the window 1015 as new input items. The window 1015 can be implemented in any desired way. For example, the window 1015 may include a circular list (such as an array) with pointers to the oldest entry. When a new input item is to be added to the window 1015, the oldest input item pointed to by the pointer can be overwritten by the new input item, and the pointer can be adjusted to point to the next oldest input item in the window 1015. Embodiments of the inventive concept can support any desired structure for storing information about the window 1015: the ring list is only one such possible data structure.

FIG. 11 illustrates using the recency logic 910 of FIG. 9 to calculate the recency weight. In FIG. 11, the recency logic 910 is depicted as calculating a recency weight 1105. The equation shown in FIG. 11 calculates a recency weight 1105 of two (the difference between the current (ie, most recent) access time of the block 810-1 and the previous access time 815-1 divided by the decay period 1110) times power. The decay period 1110 represents an adjustable variable that can control how quickly the block degrades to a lower priority stream. The decay period 1110 can be assigned to the initial value when the machine 105 of FIG. 1 is started, and can be adjusted as needed (manually by the system administrator or automatically based on the system workload). Want to prevent blocks from being promoted too fast (too fast will cause most blocks to use the same high priority stream) or too slow (Too slow will cause most blocks to stream with the same low priority). In other words, it is desirable to assign blocks to streams in a fairly uniform manner: individual streams should not be used too much or too lightly. The decay period 1110 represents the way to manage stream upgrades and downgrades to achieve this goal.

Please note that the recency weight 1105 can be changed for each block. On the other hand, the decay period 1110 should be uniform in all calculations for the recency weight 1105 (but this does not mean that the decay period 1110 cannot change with time).

FIG. 12 shows that the access count adjuster 915 of FIG. 9 uses the recency weight 1105 of FIG. 11 to adjust the access count. In FIG. 12, the access count adjuster 915 is shown calculating the adjusted access count 1205. The adjusted access count 1205 can be calculated as the access count 820-1 plus one, and then divided by the recency weight 1105. The adjusted access count 1205 can then replace the access count 820-1 and return to storage (for example) in the SFR table 805 of FIG. 8.

FIG. 13 illustrates the use of the stream ID adjuster 920 of FIG. 9 to calculate the stream ID according to the adjusted access count 1205 of FIG. 12. In FIG. 13, the stream ID adjuster 920 is shown calculating the stream ID 530-1. The stream ID 530-1 can be calculated as the logarithm of the adjusted access count 1205, and can be substituted for the stream ID 530-1 and stored back in the SFR table 805 of FIG. 8, for example. Although the mathematical term "logarithm" usually means log ₂ or log ₁₀ when it comes to computer use, you can choose to use any logarithmic function of the desired base. The selected base for the logarithmic function provides another mechanism by which the embodiment of the inventive concept can avoid too fast or too slow block promotion (and therefore, avoid excessive use of one or more device streams Insufficient use of streaming and other devices). Depending on how large the adjusted access count 1205 becomes, the stream ID adjuster 920 may also use more than one logarithmic function. For example, if the adjusted access count 1205 is lower than a certain threshold, the stream ID adjuster 920 can use log ₂ to calculate the stream ID 530-1, and if the adjusted access count 1205 is greater than the If the threshold is reached, the stream ID adjuster 920 can use log ₁₀ to calculate the stream ID 530-1.

It is worthwhile to make some notes about Figures 11-13. First, FIGS. 11 to 13 illustrate specific calculations for calculating the recency weight 1105 of FIG. 11, the adjusted access count 1205 of FIG. 12, and the stream ID 530-1. However, embodiments of the inventive concept can support the calculation of these items (or other values) in any desired manner. Since the ultimate goal is to be able to adjust the stream ID 530-1 (up or down) of FIG. 8 to fit the block ID 515-1 of FIG. 8, any desired method to achieve this result can be used. Figures 11 to 13 show only one such method.

Second, in FIGS. 11-13, the access time (such as the current access time 810-1 and the previous access time 815-1 of FIG. 11) may be based on the number of requests issued (rather than based on a specific clock ) To determine. For example, assume that the write commands 505-1 to 505-3 of FIG. 5 are issued continuously. The write command 505-1 of FIG. 5 may be the fourth write command, the write command 505-2 of FIG. 5 may be the fifth write command, and the write command 505-3 of FIG. 5 may be the sixth write command. In this example, the "access time" of various write commands can be "4", "5" and "6" respectively.

This choice to determine the access time has the following consequences: if all software sources stop sending write commands for a certain time interval (such as 1 second, or 1 minute, or 1 hour), the block's "temperature" may not change , Even if the block has not been technically accessed in a large amount of time. Therefore, even if a block has not been accessed for a large amount of time, if no other blocks are accessed during this time, the "temperature" of the block may not change. From a practical point of view, it is unlikely that all software sources can stop sending write commands at the same time. However, if the sending of the write command is stopped at the same time, the embodiment of the inventive concept will be able to handle the situation. In addition, the embodiment of the inventive concept can support the use of clock time instead of command number, which can lead to block cooling even if no software source is issuing a write command.

Compared with FIGS. 8 to 13, FIGS. 14 to 20 illustrate another embodiment of the concept of the present invention. Like the embodiment of the inventive concept shown in FIGS. 8-13, FIGS. 14-20 may include a method for mapping the block IDs 515-1 to 515-3 of FIG. 5 to the stream ID 530- of FIG. 5. The data structure of 1 to 530-3, and the implementation of the background logic 435 in FIG. 4.

FIG. 14 illustrates a second embodiment according to the inventive concept that can map the block IDs 515-1 to 515-3 of FIG. 5 to the nodes of the stream IDs 530-1 to 530-3 of FIG. 5. In FIG. 14, nodes 1405-1 to 1405-3 are shown, and node 1405-1 is shown in detail. The nodes 1405-1 to 1405-3 can be stored in any desired manner (such as arrays, link lists, and other data structures). For each block in the SSD 120 of FIG. 1, there may be one node.

The node 1405-1 may include various data, including a block ID 515-1, a stream ID 530-1, an access count 820-1, and an expiration time 1410. The block ID 515-1, stream ID 530-1, and access count 820-1 store data similar to those elements in the first embodiment of the inventive concept. The expiration time 1410 represents the "time" when the block is deemed to expire because it is not accessed by the write command. Like the first embodiment of the concept of the present invention, "time" can be measured with respect to the number of specific write commands in a sequence of all write commands, not a measurement of the clock.

FIG. 15 illustrates details of the background logic 435 of FIG. 4 according to the second embodiment of the inventive concept. In FIG. 15, the background logic 435 may include a boost logic 1505, a second queuer 1510, a storage 1515 for queues 1520-1 to 1520-3, and a down Level logic 1525. The promotion logic 1505 can promote the block to a higher priority stream when appropriate. The second queuer 1510 (so named to distinguish it from the queuer 430 of FIG. 4, but its operation is similar) can place the block IDs 515-1 to 515-3 of FIG. 5 in the queues 1520-1 to In 1520-3. The second queuer 1510 may have a structure similar to that of the queuer 430 of FIG. 4. Like the storage 1005 of FIG. 10, the storage 1515 may actually be part of the storage 330 of FIG. 3, rather than a separate storage in the background logic 435. The embodiment of the inventive concept can support any number of queues: the three queues 1520-1 to 1520-3 are just examples. In addition, there may be one queue for each stream ID 530-1 to 530-3 in FIG. 5: the number of queues 1520-1 to 1520-3 and the block IDs 515-1 to 515 in FIG. 3 that occur simultaneously The number of -3 is the same. When the block IDs 515-1 to 515-3 of FIG. 5 reach the top of the queues 1520-1 to 1520-3, the downgrade logic 1525 can determine whether to downgrade the block IDs 515-1 to 515-3 of FIG.

FIG. 16 shows the promotion and demotion of the block ID in the queues 1520-1 to 1520-3 in FIG. 15. In FIG. 16, letters a to d are used to indicate the block IDs 515-1 to 515-3 of FIG. 3. The unlabeled entries in the queues 1520-1 to 1520-3 are not used in the example shown in FIG. 16, and any block IDs that are not used in the example can be stored.

First, in FIG. 16, the submission queue 335 is shown with the block ID a at the top 1605 of the submission queue 335. Block ID a can identify blocks that have not been accessed before. Therefore, as shown by the dashed arrow 1610, the block ID a can be added to the end of the queue 1520-1 (the queue for the "coldest" stream), after which the block ID a can be removed from the submission queue 335 .

Second, in FIG. 16, the submission queue 335 may include the block ID b (which may move to the top 1605 of the submission queue 335 after the block ID a is processed). As a result of the increase in the access count 820-1 of FIG. 14 for the block ID b , the block ID b can be promoted to the "hotter" stream. As shown by the dotted arrow 1615, the block ID b can be moved from the entry 1620 of the queue 1520-1 to the end of the queue 1520-2, after which the block ID b can be removed from the submission queue 335.

Third, the degrading logic 1525 of FIG. 5 can sequentially check the tops 1625-1 to 1625-3 of the queues 1520-1 to 1520-3. For example, the downgrade logic 1525 of FIG. 15 may check the block ID c at the top 1625-3 of the queue 1520-3. If the block ID c is about to be degraded, the block ID c can be moved from the top 1625-3 of the queue 1520-3 to the end of the queue 1520-2 (the queue for the next "hottest" stream). As a result of the degradation of the block ID c , the block ID d in the queue 1520-3 can become the hottest block, as described below with reference to FIG. 17.

FIG. 17 shows details of the lifting logic 1505 of FIG. 15. In FIG. 17, the promotion logic 1505 may include an incrementer 1705, a stream ID adjuster 1710, a block expiration logic 1715, and a hottest block logic 1720. The incrementer 1705 can increment the access count 820-1 of FIG. 14 to generate an adjusted access count. The stream ID adjuster 1710 may calculate the stream ID 530-1 of FIG. 5 according to the adjusted access count, as shown in FIG. 18. The stream ID adjuster 1710 may be similar in structure to the stream ID adjuster 920 of FIG. 9.

Returning to Figure 17, the block expiration logic 1715 can determine the expiration time of the block. The expiration time of the block can be determined as the current access time of the block ID plus the device lifetime. Device life is the time interval that depends on which block is the hottest block, which will be discussed later. Figure 19 illustrates this as an equation: the expiration time 1410 is the sum of the access count 820-1 (as discussed above, it can be the current access time of the block ID 515-1 of Figure 5) and the device lifetime 1905 .

Finally, return to Figure 17 again, the hottest block logic 1720 can determine Figure 5 Does the block ID 515-1 now represent the hottest block? The hottest block can be defined as the block ID with the highest streaming priority. If there are multiple block IDs with the highest streaming priority, any selection algorithm can be used to select the specific block ID with the highest streaming priority as the hottest block. For example, the block ID representing the highest streaming priority at the top of the queue can be selected as the hottest block. Alternatively, the block ID with the most recent access (ie, the highest current access time) can be selected as the hottest block. Alternatively, the block ID indicating the highest streaming priority at the end of the queue can be selected as the hottest block. If the block ID 515-1 in FIG. 5 is now the hottest block, the device lifetime 1905 in FIG. 19 can be calculated as the current access time of the block ID 515-1 in FIG. 5 and the block ID 515- in FIG. The difference between the previous access time of 1. The device lifetime 1905 of FIG. 19 may represent the expected maximum interval between two write commands for a particular block, and may be defined based on the interval between the most recent two write commands for the hottest block. The device life 1905 of FIG. 19 can then be used to determine the expiration time 1410 of FIG. 14, which can affect when the block ID 515-1 of FIG. 14 is degraded.

FIG. 20 shows details of the downgrade logic 1525 of FIG. 15. In FIG. 20, the degrading logic 1525 is shown as including a comparator 2005 and a decrementer 2010. The comparator 2005 can compare the current time (which can also be the number of recent write requests instead of the clock time) with the expiration time 1410 of FIG. 14. If the current time exceeds the expiration time 1410 in Figure 14, the block can be considered colder than before, because the block has passed a time interval without any write command (which can be measured as Figure 19 The life of the device is 1905). In other words, if the device lifetime 1905 of FIG. 19 represents the expected number of write commands between writes to any given block, the expiration time 1410 of FIG. 14 (which can be calculated as the block ID 515- of FIG. 14) 1 plus the device lifetime 1905 in Figure 19) can indicate that the block ID 515-1 in Figure 14 can be written and is not considered The latest time when it has become cold. If the expiration time 1410 in FIG. 14 has passed, the block ID 515-1 in FIG. 14 has become somewhat colder and can be degraded. In this case, the decrementer 2010 can decrement the stream ID 530-1 of FIG. 5 to reduce the priority of the block ID 515-1 of FIG. 5, which is consistent with the decrease of the block ID 515-1 of FIG. "correspond.

If the expiration time 1410 of FIG. 14 has not passed, the block ID 515-1 of FIG. 14 has not yet become cold, and the block ID 515-1 of FIG. 14 may remain at the top of its queue. Please note that this does not mean that other block IDs in the queue will not be downgraded. Because the block IDs are placed in the queue in the order in which the blocks are accessed, the block ID 515-1 in Figure 14 is the one accessed the longest time ago (the block IDs in the queue are ) Block ID, and therefore can be the first block ID that will expire. If the block ID 515-1 of Figure 14 is accessed again (and therefore remains "hot"), the block ID 515-1 of Figure 14 can be moved to the end of the queue, leaving another block id The top of the queue is therefore potentially subject to degradation.

21A to 21B illustrate a flowchart of an example program for determining the stream ID 530-1 of FIG. 5 for the write command 505-1 of FIG. 5 according to an embodiment of the inventive concept. In FIG. 21A, at block 2105, the receiver 405 of FIG. 4 may receive the write command 505-1 from the software source. At block 2110, the LBA 510-1 of FIG. 5 can be read from the write command 505-1 of FIG. 5. At block 2115, the LBA mapper 410 of FIG. 4 may map the LBA 510-1 of FIG. 5 to the block ID 515-1 of FIG. 5. As mentioned above, the LBA mapper 410 of FIG. 5 can determine the block ID 515-1 of FIG. 5 in any desired manner: for example, by masking certain bits from the LBA 510-1 of FIG. The LBA 510-1 of 5 is divided by the block size 705 of FIG. At block 2120, the stream selection logic 415 of FIG. 5 may select the stream ID 530-1 of FIG. 5 to be used for the block ID 515-1 of FIG. 5. As mentioned above, the stream selection logic 415 of FIG. 5 can Operate in any desired way: for example, by looking up the stream ID 530-1 of FIG. 5 from the block of FIG. 3 to the stream mapper 340, and calculating the string of FIG. 5 by the access count 820-1 from FIG. 8 Stream ID 530-1, by specifying device streaming in a round-robin manner, or any other desired method. At block 2125, the stream ID adder 420 of FIG. 4 may add the stream ID 530-1 of FIG. 5 to the write command 505-1 of FIG. 5. Finally, at block 2130, the write command 505-1 of FIG. 5 may be processed by the SSD 120 of FIG. 1 to perform the indicated write operation, which may include the transmitter 425 of FIG. 4 sending the write command 505 of FIG. 5 -1 is transmitted to the SSD 120 in FIG. 1.

At this time, the write command 505-1 of FIG. 5 has been completely processed. However, other processing can still be performed, such as to update the stream ID 530-1 of FIG. 5 assigned to the block ID 515-1 of FIG. 5. At block 2135 (FIG. 21B), the queuer 430 of FIG. 4 may add the block ID 515-1 of FIG. 5 to the submission queue 335 of FIG. 3 for further processing. At block 2140, when the block ID 515-1 of FIG. 5 reaches the top of the submission queue 335 of FIG. 3, the block ID 515-1 of FIG. 5 can be removed from the submission queue 335 of FIG. 3 . Finally, at block 2145, the background logic 435 of FIG. 4 may update the stream ID 530-1 of FIG. 5 for the block ID 515-1 of FIG. 5. Various methods used by the background logic 435 of FIG. 4 to update the stream ID 530-1 of FIG. 5 for the block ID 515-1 of FIG. 5 will be described with reference to FIG. 24 and FIGS. 25A to 25C below.

FIG. 22 illustrates a flowchart of an example program of the LBA mapper 410 of FIG. 4 for mapping the LBA 510-1 of FIG. 5 to the block ID 515-1 of FIG. 5 according to an embodiment of the inventive concept. In FIG. 22, at block 2205, the LBA mapper 410 of FIG. 4 can use the address mask 525 of FIG. 5 to mask the bits from the LBA 510-1 of FIG. 1, thereby leaving the block ID of FIG. 5. 515-1. Alternatively, at block 2210, the LBA mapper 410 of FIG. 4 may divide LBA 510-1 of FIG. 5 by the block size of FIG. 7 705 to determine the block ID 515-1 in FIG. 5.

FIGS. 23A to 23B illustrate a flowchart of an example program for using sequential logic to determine the stream ID 530-1 of FIG. 5 for the block ID 515-1 of FIG. 5 according to the first embodiment of the inventive concept . In FIG. 23A, at block 2305, the stream selection logic 415 of FIG. 4 may determine whether to test the sequential LBAs in the write commands 505-1 to 505-3. For example, in an embodiment of the inventive concept using a multi-queue method, the stream selection logic 415 of FIG. 4 may not consider whether the write command 505-1 of FIG. 5 is followed by an earlier write command. If the stream selection logic 415 of FIG. 4 does not test the sequential write command, then at block 2310, the stream selection logic 415 of FIG. 4 can determine the diagram currently associated with the block ID 515-1 of FIG. 5 Stream ID 530-1 of 5: For example, access the stream ID 530-1 of FIG. 5 from the block to stream mapper 340 in FIG. 3. How the stream selection logic 415 of FIG. 4 determines the characteristics of the stream ID 530-1 of FIG. 5 may depend on how the block-to-stream mapper 340 of FIG. 3 is implemented: if the block-to-stream mapper 340 includes a graph 8 SFR table 805, the stream selection logic 415 of FIG. 4 can perform a table lookup; if the block-to-stream mapper 340 includes the nodes 1405-1 to 1405-3 of FIG. 14, the stream selection logic of FIG. 4 415 will have to search for the node to find the block ID 515-1 of FIG. 5 before determining the stream ID 530-1 of FIG. 5.

On the other hand, if the stream selection logic 415 of FIG. 4 tests the sequential write command, at block 2315, the stream selection logic 415 of FIG. 4 can identify the input items 1020-1 to 1020-8 of FIG. The window 1015 of FIG. 10. At block 2320, the stream selection logic 415 of FIG. 4 can determine whether the LBA 510-1 of FIG. 5 is connected to any input item 1020-1 to 1020-8 of FIG. 10 in the window 1015 of FIG. 10 LBA 1030. If the LBA 515-1 of FIG. 5 does not follow any input items 1020-1 to 1020-8 of FIG. 10 in the window 1015 of FIG. 10, the end LBA of FIG. 10 1030, as described above, at block 2310, the stream selection logic 415 of FIG. 4 can determine the stream ID 530-1 of FIG. 5 that is currently associated with the block ID 515-1 of FIG. 5.

If the stream selection logic 415 of FIG. 4 tests the sequential write command and the LBA 510-1 of FIG. 5 continues any of the input items 1020-1 to 1020-8 of FIG. 10 in the window 1015 of FIG. 10, then the block At 2325 (FIG. 23B), the stream selection logic 415 of FIG. 4 can determine the stream ID 530-1 of FIG. 5 assigned to the previous write command. At block 2125 (part of FIGS. 21A-21B, and therefore shown in dashed lines in FIG. 23B for illustrative purposes), the stream ID 530-1 of FIG. 5 assigned to the previous write command may be assigned Assign to the write command 505-1 of FIG. 5. At block 2330, the stream selection logic 415 of FIG. 4 can identify the input items 1020-1 to 1020-8 of FIG. 10, which are the oldest input items in the window 1015 of FIG. 10. Finally, at block 2335, the stream selection logic 415 of FIG. 4 may remove the oldest input item in the window 1015 of FIG. 10 and add a new input item corresponding to the write command 505-1 of FIG. 5. The mechanism of how the stream selection logic 415 of FIG. 4 performs this deletion and addition depends on the structure used for the window 1015 of FIG. 10. If the window 1015 of FIG. 10 stores the array or link list of input items 1020-1 to 1020-8 in FIG. 10, deleting and adding can almost involve overwriting the oldest input item with a new value and updating to the top of the array or link list index of. On the other hand, using a different structure for the window 1015 of FIG. 10, deletion and addition may involve deleting and de-allocating the memory object for the oldest entry and allocating a new memory object for the write command 505-1 of FIG. 5.

FIG. 24 illustrates a flowchart of an example program for performing background update of the SFR table 805 of FIG. 8 according to the first embodiment of the inventive concept. In FIG. 24, at block 2405, the access count adjuster 905 of FIG. 9 may increment the access count 820-1 of FIG. 8 (for example, using an incrementer or ALU). At block 2410, the recent The degree logic 910 can calculate (eg, using ALU) the recency weight 1105 of FIG. 11. At block 2415, the access count adjuster 905 of FIG. 9 may divide the access count 820-1 of FIG. 8 (incremented in block 2405) by (eg, using ALU) the recency weight 1105 of FIG. 11. Finally, at block 2420, the stream ID adjuster 920 of FIG. 9 can determine the new stream ID associated with the block ID 515-1 of FIG. 5. For example, the stream ID adjuster 920 of FIG. 9 may use ALU to calculate the logarithm of the adjusted access count 1205 of FIG. 12.

25A to 25C are flowcharts of an example program for performing background update of the node 1405-1 in FIG. 14 according to the second embodiment of the inventive concept. In FIG. 25A, at block 2505, the incrementer 1705 of FIG. 17 may increment the access count 820-1 of FIG. 14. At block 2510, the block expiration logic 1715 of FIG. 17 can determine the expiration time 1410 of FIG. 14 for the block ID 515-1 of FIG. 14. At block 2515, the stream ID adjuster 1710 of FIG. 17 can determine the stream ID 530-1 of FIG. 14 for the block ID 515-1 of FIG. 14. The stream ID adjuster 1710 of FIG. 17 can determine the stream ID 530-1 of FIG. 14 by, for example, accessing the stream ID 530-1 of FIG. 14 from the node 1405-1 of FIG. 14. At block 2520, the second queuer 1510 of FIG. 15 can place the block ID 515-1 of FIG. 14 in the queues 1520-1 to 1520-3 of FIG. 15 corresponding to the stream ID of FIG. 14 530-1 in the queue.

At block 2525 (FIG. 25B), the hottest block logic 1720 of FIG. 17 can compare the access count 820-1 of FIG. 14 of the block ID 515-1 of FIG. 14 with the access count of the hottest block. If the access count 820-1 of FIG. 14 of the block ID 515-1 of FIG. 14 is greater than the access count of the hottest block, the block ID 515-1 of FIG. 14 is now the hottest block. Therefore, at block 2530, the hottest block logic 1720 of FIG. 17 can identify the block ID 515-1 of FIG. 14 as the new hottest block, and at block 2535, FIG. 17 The hottest block logic 1720 can determine that the device lifetime 1905 of FIG. 19 is the time difference between the two most recent accesses of the block ID 515-1 of FIG. 14.

Regardless of whether the block ID 515-1 of FIG. 14 is the hottest block, at block 2540, the comparator 2005 of FIG. 20 can be in the queue of FIG. 15 with the block ID 515-1 of FIG. At the top of one of 1520-3, it is determined whether the expiration time 1410 of FIG. 14 has passed. If it has not passed, the background logic 435 of FIG. 4 may wait (while performing other operations) and check again at the block 2540 until the expiration time 1410 of FIG. 14 of the block ID 515-1 of FIG. 14 has passed. At that time, at block 2545, the degrading logic 1525 of FIG. 15 can remove the block ID 515-1 of FIG. 14 from the queues 1520-1 to 1520-3 of FIG. 15. Next, at block 2550, the decrementer 2010 of FIG. 20 can decrement the stream ID 530-1 of FIG. 14.

At block 2555 (FIG. 25C), the second queuer 1510 of FIG. 15 can place the block ID 515-1 of FIG. 14 in the queues 1520-1 to 1520-3 of FIG. 15 corresponding to the new string In another queue of the stream ID. At block 2560, the downgrade logic 1525 of FIG. 15 can determine whether the block ID 515-1 of FIG. 14 is the hottest block. If so, at block 2565, the downgrade logic 1525 of FIG. 15 can select another block ID as the new hottest block. For example, another block assigned to the stream ID 530-1 of FIG. 14 may be selected (before the decrement in block 2560), such as the block ID at the top or end of the queue. As mentioned above, the downgrade logic 1525 of FIG. 15 can also calculate the device lifetime 1905 of FIG. 19 based on the selected new hottest block.

In FIGS. 21A to 25C, some embodiments of the inventive concept are illustrated. However, those familiar with the art will recognize that other embodiments of the inventive concept are also possible by changing the order of the blocks, by omitting blocks, or by including links not shown in the drawings. All such changes in the flowchart are considered to be the implementation of the concept of the invention Example, whether or not explicitly described.

The following discussion is intended to provide a brief, general description of suitable machines or certain aspects of machines that can implement the inventive concept. The machine can be at least partially driven by input from conventional input devices (such as keyboards, mice, etc.), as well as guidance, biometric feedback, or other input received from another machine (interacting with a virtual reality (VR) environment) Signal to control. As used herein, the term "machine" is intended to broadly cover a single machine, a virtual machine, or a system of co-operating and communicatively coupled machines, virtual machines, or devices. Exemplary machines include computing devices, such as personal computers, workstations, servers, portable computers, handheld devices, phones, tablets, etc.; and transportation devices, such as private or public transportation, such as cars, trains, taxis, etc.

The machine may include embedded controllers, such as programmable or non-programmable logic devices or arrays, application specific integrated circuits (ASICs), embedded computers, smart cards, and the like. The machine can utilize one or more connections to one or more remote machines, such as via a network interface, modem, or other communication coupling. Machines can be interconnected by means of physical and/or logical networks (such as corporate intranet, Internet, local area network, wide area network, etc.). Those familiar with this technology will understand that network communications can utilize various wired and/or wireless short-range or long-range carriers and protocols, including radio frequency (RF), satellite, microwave, and Institute of Electrical and Electronics Engineers (Institute of Electrical and Electronics). Engineers; IEEE) 802.11, Bluetooth®, optics, infrared, cables, lasers, etc.

The embodiments of the concept of the present invention can be described by reference or in combination with related data, which includes functions, procedures, data structures, applications, etc. When the machine is accessed, the machine performs tasks or defines abstract data types or low-level hardware contexts. Related data can be stored in (for example) volatile and/or non-volatile memory (for example, RAM, ROM, etc.), or stored in other storage devices and their associated storage media, including hard drives, floppy disks , Optical storage, magnetic tape, flash memory, memory stick, digital video disk, biological storage, etc. The associated data can be transmitted through the transmission environment (including physical and/or logical networks) in the form of packets, serial data, parallel data, propagated signals, etc., and can be used in compressed or encrypted formats. The associated data can be used in a distributed environment and stored locally and/or remotely for machine access.

Embodiments of the inventive concept may include a tangible non-transitory machine-readable medium that includes instructions executable by one or more processors, the instructions including instructions for executing elements of the inventive concept as described herein instruction.

Having described and illustrated the principles of the inventive concept with reference to the illustrated embodiments, it will be appreciated that the illustrated embodiments can be modified in configuration and details without departing from these principles, and can be combined in any desired manner. And although the foregoing discussion focuses on specific embodiments, other configurations are covered. In particular, although expressions such as "an embodiment according to the concept of the present invention" or the like are used herein, these phrases mean generally referring to the embodiment possibilities, and are not intended to limit the concept of the present invention to specific implementations Example configuration. As used herein, these terms may refer to the same or different embodiments combined into other embodiments.

The foregoing illustrative embodiments should not be construed as limiting the inventive concept thereof. Although several embodiments have been described, those skilled in the art will easily understand that many modifications to these embodiments are possible without materially departing from the novel teachings and advantages of the present disclosure. Therefore, all such modifications are intended to be included in the Within the scope of the inventive concept defined in the scope of interest.

The embodiments of the concept of the present invention can extend the following description without limitation:

Description 1. Embodiments of the concept of the present invention include a solid state drive (SSD), which includes: flash memory for storing data; support for streaming of multiple devices in the SSD; and an SSD controller for The management responds to a plurality of write commands to write data to the flash memory, the SSD controller includes a storage for submitting queues and blocks to the stream mapper; and a flash translation layer, which Contains: a receiver to receive a write command including a logical block address (LBA); an LBA mapper to map the LBA to a block identifier (ID); stream selection logic to use The block-to-stream mapper selects a stream ID based on the block ID; a stream ID adder for adding the stream ID to the write command; a queuer for Placing the block ID in the submission queue; and background logic for removing the block ID from the submission queue and updating the block to the stream mapper.

Narration 2. An embodiment of the inventive concept includes the SSD according to Narration 1, and further includes a transmitter for transmitting the write command with the stream ID to the SSD.

Statement 3. An embodiment of the inventive concept includes the SSD according to Statement 1, wherein the LBA mapper includes an address mask for masking a portion of the LBA to determine the block ID.

Statement 4. An embodiment of the inventive concept includes the SSD according to Statement 1, wherein the LBA mapper includes an arithmetic logic unit (ALU) to divide the LBA by a block size to identify the block ID.

Statement 5. An embodiment of the inventive concept includes the SSD according to Statement 1, wherein the block-to-stream mapper includes a sequence, frequency, recency (SFR) table, and the SFR table includes the block ID and target The stream ID of the block ID.

Statement 6. An embodiment of the inventive concept includes the SSD according to Statement 5, wherein the background logic includes sequential logic to select a previous stream if the LBA is followed by a second LBA of a previous write command.

Statement 7. An embodiment of the inventive concept includes the SSD according to Statement 6, wherein the previous write command is in a window prior to the write command, and the window includes a window size.

Statement 8. An embodiment of the inventive concept includes the SSD according to Statement 7, wherein the window size is determined in response to at least one of the following: the number of cores in the processor in the host computer system, and The number of software sources running on the processor in the host computer system.

Statement 9. An embodiment of the inventive concept includes the SSD according to Statement 7, wherein the SSD controller further includes a storage for a previous write command queue including the previous write command, the queue including all The last LBA and corresponding stream ID of each of the previous write commands are described.

Statement 10. An embodiment of the inventive concept includes the SSD according to Statement 5, wherein the background logic includes: recency logic to be based on the current access time for the block ID and the previous for the block ID Access time and decay period to calculate recency weight; An access count adjuster for adjusting the access count of the block ID based on the recency weight to generate an adjusted access count; and a stream ID adjuster for adjusting the access count for the block ID based on The adjusted access count of to adjust the stream ID.

Statement 11. The embodiment of the inventive concept includes the SSD according to Statement 10, wherein the SFR table further includes the current access time of the block ID, the previous access time of the block ID, and all The access count of the block ID.

Statement 12. An embodiment of the inventive concept includes the SSD according to Statement 10, wherein the recency logic calculates the recency weight as two (the current access time of the block ID and the block The difference between the previous access times of IDs is divided by the power of the decay period).

Statement 13. An embodiment of the inventive concept includes the SSD according to Statement 10, wherein the access count adjuster calculates the adjusted access count for the block ID as (the block ID The access count plus one) is divided by the recency weight.

Statement 14. An embodiment of the inventive concept includes the SSD according to Statement 10, wherein the stream ID adjuster calculates the stream ID as the logarithm of the adjusted access count for the block ID.

Statement 15. An embodiment of the inventive concept includes the SSD according to Statement 1, wherein the block-to-stream mapper includes a node entry, and the node entry includes the block ID and addresses the The stream ID of the block ID.

Narration 16. An embodiment of the inventive concept includes the SSD according to Narration 15, wherein the background logic includes: promotion logic for determining when to promote the stream ID based on the block ID; The second queuer is used to respond to the stream ID for the block ID and place the block ID in the first queue of the plurality of queues corresponding to the plurality of stream IDs Medium; and a downgrade logic to determine when to downgrade the stream ID based on the block ID.

Statement 17. An embodiment of the inventive concept includes the SSD according to Statement 16, wherein the boost logic includes: an incrementer to increment the access count of the block ID; and a stream ID adjuster The stream ID is determined in response to the access count of the block ID.

Narration 18. An embodiment of the inventive concept includes the SSD according to Narration 17, wherein the stream ID adjuster is operative to determine the stream ID as the logarithm of the access count of the block ID .

Statement 19. An embodiment of the inventive concept includes the SSD according to Statement 17, wherein the promotion logic further includes block expiration logic for calculating the expiration time of the block ID.

Statement 20. An embodiment of the inventive concept includes the SSD according to Statement 19, wherein the block expiration logic is operative to calculate the expiration time of the block ID as all of the block ID The sum of the access count and the life of the device.

Statement 21. An embodiment of the inventive concept includes the SSD according to Statement 20, wherein the device lifetime is the difference between the last access time of the hottest block and the previous access time of the hottest block.

Statement 22. The embodiment of the inventive concept includes the SSD according to Statement 21, wherein the promotion logic further includes the hottest block logic, which is used in the block ID If the access count is greater than the last access count of the hottest block, the block ID is identified as the hottest block.

Statement 23. An embodiment of the inventive concept includes the SSD according to Statement 21, wherein the node entry further includes the access count of the block ID and the expiration time of the block ID.

Statement 24. An embodiment of the inventive concept includes the SSD according to Statement 16, wherein: the degradation logic includes: a comparator to determine whether the expiration time of the block ID has passed; and the block ID A decrementer used to decrement the stream ID when the expiration time of the elapsed time; and the second queuer is operative to respond to the decrement of the block ID Stream ID, placing the block ID in the second queue of the plurality of queues corresponding to the plurality of stream IDs.

Statement 25. Embodiments of the inventive concept include the SSD according to Statement 24, wherein the downgrade logic is operative to be based on when the block ID is in the first queue of the plurality of queues The block ID at the top is used to determine when to downgrade the stream ID.

Statement 26. An embodiment of the inventive concept includes the SSD according to Statement 24, wherein the downgrading logic is operative to be based on the first queue of the plurality of queues where the block ID is The block ID in the top case is used to determine when to downgrade the stream ID.

Description 27. Embodiments of the inventive concept include a drive for use in a computer system, which includes: a receiver for receiving a write command for a solid state drive (SSD), the The write command includes a logical block address (LBA); an LBA mapper to map the LBA to a block identifier (ID); stream selection logic to use the memory stored in the host computer system The block-to-stream mapper in, selects the stream ID based on the block ID; the stream ID adder, which adds the stream ID to the write command; the queuer, uses To place the block ID in the commit queue stored in the memory; and background logic to remove the block ID from the commit queue and update the block to the string Stream mapper.

Narration 28. An embodiment of the inventive concept includes the drive according to Narration 27, and further includes a transmitter for transmitting the write command with the stream ID to the SSD.

Statement 29. An embodiment of the inventive concept includes the driver according to Statement 27, wherein the LBA mapper includes an address mask for masking a portion of the LBA to identify the block ID.

Statement 30. An embodiment of the inventive concept includes the driver according to Statement 27, wherein the LBA mapper includes an arithmetic logic unit (ALU) to divide the LBA by a block size to identify the block ID.

Statement 31. An embodiment of the inventive concept includes a driver according to Statement 27, wherein the block-to-stream mapper includes a sequence, frequency, recency (SFR) table, and the SFR table includes the block ID and target The stream ID of the block ID.

Narration 32. An embodiment of the inventive concept includes the drive according to Narration 31, wherein the background logic includes sequential logic to select a previous stream if the LBA is followed by a second LBA of a previous write command.

Statement 33. An embodiment of the inventive concept includes the drive according to Statement 32, wherein the previous write command is in a window prior to the write command, the window including the window size.

Statement 34. An embodiment of the inventive concept includes a driver according to Statement 33, wherein the window size is determined in response to at least one of the following: the number of cores in the processor in the host computer system, and The number of software sources running on the processor in the host computer system.

Narrative 35. An embodiment of the inventive concept includes the driver according to Narrative 31, wherein the background logic includes: recency logic to be based on the current access time for the block ID, the previous for the block ID The access time and the decay period are used to calculate the recency weight; the access count adjuster is used to adjust the access count of the block ID based on the recency weight to generate the adjusted access count; and the stream ID An adjuster to adjust the stream ID based on the adjusted access count for the block ID.

Narration 36. An embodiment of the inventive concept includes the drive according to Narration 35, wherein the SFR table further includes the current access time of the block ID, the previous access time of the block ID, and all The access count of the block ID.

Narrative 37. An embodiment of the inventive concept includes the driver according to Narrative 35, wherein the recency logic calculates the recency weight as two (the current access time of the block ID and the block The difference between the previous access times of IDs is divided by the power of the decay period).

Narration 38. An embodiment of the inventive concept includes a driver according to Narration 35, wherein the access count adjuster adjusts the adjusted access count for the block ID It is calculated as (the access count of the block ID plus one) divided by the recency weight.

Narration 39. An embodiment of the inventive concept includes the driver according to Narration 35, wherein the stream ID adjuster calculates the stream ID as the logarithm of the adjusted access count for the block ID.

Narrative 40. An embodiment of the inventive concept includes a driver according to Narrative 27, wherein the block-to-stream mapper includes a node entry, and the node entry includes the block ID and a reference to the block ID The stream ID.

Narrative 41. An embodiment of the inventive concept includes a driver according to Narrative 40, wherein the background logic includes: promotion logic for determining when to promote the stream ID based on the block ID; a second queuer, In response to the stream ID for the block ID, placing the block ID in the first queue of the plurality of queues corresponding to the plurality of stream IDs; and the downgrade logic, It is used to determine when to downgrade the stream ID based on the block ID.

Statement 42. An embodiment of the inventive concept includes the driver according to Statement 41, wherein the boost logic includes: an incrementer to increment the access count of the block ID; and a stream ID adjuster to The stream ID is determined in response to the access count of the block ID.

Narration 43. An embodiment of the inventive concept includes the driver according to Narration 42, wherein the stream ID adjuster is operative to determine the stream ID as the logarithm of the access count of the block ID .

Statement 44. An embodiment of the inventive concept includes the driver according to Statement 42, wherein the promotion logic further includes block expiration logic for calculating the expiration time of the block ID.

Narrative 45. An embodiment of the inventive concept includes a driver according to Narrative 44, wherein the block expiration logic is operative to calculate the expiration time of the block ID as all of the block ID The sum of the access count and the life of the device.

Statement 46. An embodiment of the inventive concept includes the drive according to Statement 45, wherein the device lifetime is the difference between the last access time of the hottest block and the previous access time of the hottest block.

Narrative 47. An embodiment of the inventive concept includes the driver according to Narrative 46, wherein the promotion logic further includes the hottest block logic, which is used when the access count of the block ID is greater than the hottest zone In the case of the last access count of the block, the block ID is identified as the hottest block.

Statement 48. An embodiment of the inventive concept includes the driver according to Statement 46, wherein the node entry further includes the access count of the block ID and the expiration time of the block ID.

Narration 49. An embodiment of the inventive concept includes the driver according to Narration 41, wherein: the downgrade logic includes: a comparator for determining whether the expiration time of the block ID has passed; and the block ID A decrementer used to decrement the stream ID when the expiration time of the elapsed time; and the second queuer is operative to respond to the decrement of the block ID Stream ID, and place the block ID in all corresponding to the multiple stream IDs In the second queue of the multiple queues.

Narration 50. An embodiment of the inventive concept includes the driver according to Narration 49, wherein the downgrading logic is operative to be based on when the block ID is in the first queue of the plurality of queues The block ID at the top is used to determine when to downgrade the stream ID.

Statement 51. An embodiment of the inventive concept includes the driver according to Statement 49, wherein the downgrading logic is operative to be based on the first queue in the plurality of queues where the block ID is The block ID in the top case is used to determine when to downgrade the stream ID.

Description 52. An embodiment of the concept of the present invention includes a method including: receiving a write command from a software source; determining the logical block address (LBA) in the write command; identifying that a solid state drive (SSD) contains The block identifier (ID) of the block of the LBA; access the stream ID associated with the block ID; assign the stream ID to the write command; process on the SSD Use the write command of the specified stream ID; and perform background update of the stream ID associated with the block ID.

Statement 53. Embodiments of the inventive concept include the method according to Statement 52, wherein the method is implemented in one of a file system layer, a block layer, or a device driver layer on the host computer system.

Narrative 54. Embodiments of the inventive concept include the method according to Narrative 52, wherein the method is implemented in the flash translation layer of the SSD.

Statement 55. An embodiment of the inventive concept includes a method according to Statement 52, wherein a block identifier (ID) that identifies a block on a solid state drive (SSD) that contains the LBA includes using an address mask for the LBA To identify the block ID.

Statement 56. An embodiment of the inventive concept includes the method according to Statement 52, wherein the block identifier (ID) that identifies the block on a solid state drive (SSD) that contains the LBA includes dividing the LBA by the zone The number of sectors in the block.

Narration 57. An embodiment of the inventive concept includes the method according to Narration 52, wherein assigning the stream ID to the write command includes adding the stream ID to the write command as a tag.

Narration 58. The embodiment of the inventive concept includes the method according to Narration 52, further comprising: determining whether the logical block address is connected to the second LBA in the second write command; and connecting to the logical block address In the case of the second LBA in the second write command: determine the second stream ID assigned to the second write command; and assign the second stream ID to the write command.

Narration 59. An embodiment of the inventive concept includes the method according to Narration 58, wherein the second write command is in a window prior to the write command.

Narration 60. Embodiments of the inventive concept include the method according to Narration 59, and further include identifying the window.

Statement 61. An embodiment of the inventive concept includes the method according to Statement 60, wherein identifying the window includes identifying the window size in response to at least one of the following: in a processor in a host computer system that includes the SSD The number of cores, And the number of software sources executed on the processor in the host computer system including the SSD.

Narration 62. The embodiment of the inventive concept includes the method according to Narration 59, further comprising: identifying the oldest write command in the window; and replacing the oldest write command in the window with the write command command.

Narration 63. An embodiment of the inventive concept includes the method according to Narration 52, wherein performing a background update of the stream ID associated with the block ID includes: adding the block ID to a submission queue; and When the block ID is at the top of the submission queue, the block ID is removed from the submission queue.

Statement 64. An embodiment of the inventive concept includes the method according to Statement 52, wherein performing a background update of the stream ID associated with the block ID includes: increasing the access count of the block ID; responding Calculating the recency weight of the block ID based on the current access time and the previous access time of the block ID; updating the access count of the block ID in response to the recency weight; and The stream ID for the block ID is determined in response to the updated access count.

Statement 65. An embodiment of the inventive concept includes the method according to Statement 64, wherein calculating the recency weight of the block ID in response to the current access time and the previous access time of the block ID includes: The recency weight is calculated as two (the difference between the current access time and the previous access time of the block ID divided by the attenuation Period) power.

Statement 66. An embodiment of the inventive concept includes the method according to Statement 65, wherein updating the access count of the block ID in response to the recency weight includes dividing the access count by the recency Degree weight.

Statement 67. An embodiment of the inventive concept includes the method according to Statement 64, wherein determining that the stream ID for the block ID is included in response to the updated access count The stream ID of is calculated as the logarithm of the updated access count.

Narration 68. An embodiment of the inventive concept includes the method according to Narration 52, wherein performing a background update of the stream ID associated with the block ID includes: placing the block ID corresponding to the In the queue of stream IDs, the queue corresponding to the stream ID is one of a plurality of queues; and when the block ID reaches the top of the queue, it is determined whether to The block ID is degraded.

Statement 69. Embodiments of the inventive concept include the method according to Statement 68, wherein placing the block ID in a queue corresponding to the stream ID includes: incrementing the access count of the block ID And in response to the access count of the block ID to determine the stream ID for the block ID.

Statement 70. Embodiments of the inventive concept include the method according to Statement 69, wherein in response to the access count of the block ID, it is determined that the stream ID for the block ID includes, and the stream ID for the block ID The stream ID of the ID is calculated as the logarithm of the access count of the block ID.

Narration 71. Embodiments of the inventive concept include the method according to Narration 69, wherein Placing the block ID in a queue corresponding to the stream ID further includes, in the case where the access count of the block ID exceeds the second access count of the hottest block, Identify the block ID as the new hottest block.

Statement 72. Embodiments of the inventive concept include the method according to Statement 71, wherein identifying the block ID as the new hottest block includes determining the device life as the current access time of the block ID and all The difference between the previous access time of the block ID.

Statement 73. An embodiment of the inventive concept includes the method according to Statement 68, wherein: performing a background update of the stream ID associated with the block ID further includes determining in response to the access count and device lifetime The expiration time of the block ID; and determining whether to include the block ID downgrade when the block ID reaches the top of the queue, when the expiration time of the block ID has passed In the case of: removing the block ID from the queue corresponding to the stream ID; decrementing the stream ID; and placing the block ID in the string corresponding to the decrement In the second queue of the stream ID.

Statement 74. Embodiments of the inventive concept include the method according to Statement 73, wherein determining the expiration time of the block ID in response to the access count and device life includes determining the device life as the hottest block The difference between the last access time and the previous access time of the hottest block.

Statement 75. The embodiment of the inventive concept includes the method according to Statement 73, wherein it is determined whether to degrade the block ID to include more when the block ID reaches the top of the queue. When the expiration time has passed and when the block ID is the hottest block, select the one corresponding to the stream ID The second block ID in the queue is used as the new hottest block.

Description 76. An embodiment of the inventive concept includes an object including a non-transitory storage medium on which is stored instructions that when executed by a machine cause the following operations: receiving a write command from a software source ; Determine the logical block address (LBA) in the write command; identify the block identifier (ID) of the block containing the LBA on the solid state drive (SSD); access and the block ID The associated stream ID; assign the stream ID to the write command; process the write command using the designated stream ID on the SSD; and perform execution related to the block ID The background update of the linked stream ID.

Statement 77. An embodiment of the inventive concept includes an object according to Statement 76, wherein the method is implemented in one of a file system layer, a block layer, or a device driver layer on a host computer system.

Narration 78. Embodiments of the inventive concept include the object according to Narration 76, wherein the method is implemented in the flash translation layer of the SSD.

Statement 79. An embodiment of the inventive concept includes an object according to Statement 76, wherein a block identifier (ID) that identifies a block on a solid state drive (SSD) that contains the LBA includes using an address mask for the LBA To identify the block ID.

Statement 80. An embodiment of the inventive concept includes an object according to Statement 76, wherein a block identifier (ID) that identifies a block on a solid state drive (SSD) that contains the LBA includes dividing the LBA by the area The number of sectors in the block.

Narrative 81. An embodiment of the inventive concept includes an item according to Narrative 76, wherein assigning the stream ID to the write command includes adding the stream ID to the write command as a tag.

Narration 82. An embodiment of the inventive concept includes an object according to Narration 76, on which the non-transitory storage medium stores other instructions that cause the following operations when executed by the machine: Determine the logical block address Whether to continue the second LBA in the second write command; and in the case where the logical block address is continued with the second LBA in the second write command: determine whether to assign to the second write The second stream ID of the command; and assign the second stream ID to the write command.

Narrative 83. An embodiment of the inventive concept includes an object according to Narrative 82, wherein the second write command is in a window prior to the write command.

Narrative 84. An embodiment of the inventive concept includes an object according to Narrative 83, on which the non-transitory storage medium stores other instructions that cause the window to be recognized when executed by the machine.

Statement 85. An embodiment of the inventive concept includes an object according to Statement 84, wherein identifying the window includes identifying the window size of the window in response to at least one of the following: In a host computer system that includes the SSD The number of cores in the processor, and the number of software sources running on the processor in the host computer system that includes the SSD.

Narrative 86. An embodiment of the inventive concept includes an object according to Narrative 83, on which the non-transitory storage medium stores the following operations when executed by the machine Other instructions performed: identify the oldest write command in the window; and replace the oldest write command in the window with the write command.

Narrative 87. An embodiment of the inventive concept includes an object according to narrative 76, wherein performing a background update of the stream ID associated with the block ID includes: adding the block ID to a submission queue; and When the block ID is at the top of the submission queue, the block ID is removed from the submission queue.

Narrative 88. An embodiment of the inventive concept includes an object according to Narrative 76, wherein performing a background update of the stream ID associated with the block ID includes: increasing the access count of the block ID; responding Calculating the recency weight of the block ID based on the current access time and the previous access time of the block ID; updating the access count of the block ID in response to the recency weight; and The stream ID for the block ID is determined in response to the updated access count.

Statement 89. An embodiment of the inventive concept includes an object according to Statement 88, wherein calculating the recency weight of the block ID in response to the current access time and the previous access time of the block ID includes: The recency weight is calculated as the power of two (the difference between the current access time and the previous access time of the block ID divided by the decay period).

Statement 90. An embodiment of the inventive concept includes an object according to Statement 89, wherein updating the access count of the block ID in response to the recency weight includes, The access count is divided by the recency weight.

Narrative 91. An embodiment of the inventive concept includes an object according to Narrative 88, wherein in response to the updated access count, it is determined that the stream ID for the block ID includes, and the block ID is The stream ID of is calculated as the logarithm of the updated access count.

Narrative 92. An embodiment of the inventive concept includes an object according to narrative 76, wherein performing a background update of the stream ID associated with the block ID includes: placing the block ID corresponding to the In the queue of stream IDs, the queue corresponding to the stream ID is one of a plurality of queues; and when the block ID reaches the top of the queue, it is determined whether to The block ID is degraded.

Statement 93. An embodiment of the inventive concept includes the object according to Statement 92, wherein placing the block ID in a queue corresponding to the stream ID includes: incrementing the access count of the block ID And in response to the access count of the block ID to determine the stream ID for the block ID.

Statement 94. An embodiment of the inventive concept includes an object according to Statement 93, wherein in response to the access count of the block ID, it is determined that the stream ID for the block ID contains The stream ID of the ID is calculated as the logarithm of the access count of the block ID.

Narration 95. The embodiment of the inventive concept includes the object according to Narration 93, wherein placing the block ID in a queue corresponding to the stream ID is further included in the storage of the block ID If the second access count exceeds the hottest block, the block ID is identified as the new hottest block.

Narrative 96. The embodiment of the inventive concept includes an object according to Narrative 95, wherein identifying the block ID as the new hottest block includes determining the device life as the current access time of the block ID and all The difference between the previous access time of the block ID.

Narrative 97. An embodiment of the inventive concept includes an object according to Narrative 92, wherein: performing the background update of the stream ID associated with the block ID further includes determining in response to the access count and device lifetime The expiration time of the block ID; and determining whether to include the block ID downgrade when the block ID reaches the top of the queue, when the expiration time of the block ID has passed In the case of: removing the block ID from the queue corresponding to the stream ID; decrementing the stream ID; and placing the block ID in the string corresponding to the decrement In the second queue of the stream ID.

Statement 98. The embodiment of the inventive concept includes the object according to Statement 97, wherein determining the expiration time of the block ID in response to the access count and device life includes determining the device life as the hottest block The difference between the last access time and the previous access time of the hottest block.

Narrative 99. The embodiment of the inventive concept includes an object according to Narrative 97, in which it is determined whether to degrade the block ID to include more when the block ID reaches the top of the queue. When the expiration time has passed and the block ID is the hottest block, the second block ID in the queue corresponding to the stream ID is selected as the new hottest block. Hot block.

Therefore, in view of the wide variety of changes in the embodiments described herein, this detailed description and accompanying materials are only intended to be illustrative and should not be considered as limiting The scope of the inventive concept. The claimed concept of the invention is therefore capable of all such modifications within the scope and spirit of the following patent applications and their equivalents.

120: Solid State Drive (SSD)

305: host interface logic

310: SSD controller

315-1, 315-2, 315-3, 315-4, 315-5, 315-6, 315-7, 315-8: Flash memory chip

320-1, 320-2, 320-3, 320-4: channels

325: Flash Translation Layer

330: Storage

335: Submit Queue

340: block to stream mapper

Claims (20)

A solid state drive (SSD) includes: a flash memory for storing data; a solid state hard disk controller for managing writing data to the flash memory in response to a plurality of write commands, the The solid-state drive controller includes storage for submitting queues and blocks to a stream mapper, the solid-state drive controller enables the solid-state drive to support streaming to multiple devices; and a flash translation layer , Including: a receiver to receive a write command including a logical block address (LBA); an LBA mapper to map the LBA to a block identifier (ID); stream selection logic to Use the block-to-stream mapper to select a stream ID based on the block ID; a stream ID adder to add the stream ID to the write command; a queuer to use To place the block ID in the submission queue; and background logic to remove the block ID from the submission queue and update the block-to-stream mapper. The solid state drive described in claim 1, wherein the block-to-stream mapper includes a sequence, frequency, and recency (SFR) table, and the SFR table includes the block ID and the The stream ID of the block ID. The solid-state drive described in claim 2, wherein the background logic includes sequential logic for selecting the previous stream ID when the LBA is followed by the second LBA of the previous write command. The solid state drive described in item 2 of the scope of patent application, wherein the background logic includes: The recency logic is used to calculate the recency weight based on the current access time for the block ID, the previous access time for the block ID, and the decay period; an access count adjuster is used to calculate the recency weight based on the The recency weight is used to adjust the access count of the block ID to generate an adjusted access count; and a stream ID adjuster is used to adjust the access count based on the adjusted access count for the block ID The stream ID. The solid-state drive described in claim 1, wherein the block-to-stream mapper includes a node input item, and the node input item includes the block ID and the block ID Stream ID. The solid state drive according to claim 5, wherein the background logic includes: promotion logic to determine when to promote the stream ID based on the block ID; and a second queuer to In response to the stream ID for the block ID, the block ID is placed in the first queue of the plurality of queues corresponding to the plurality of stream IDs; and the downgrade logic is used for Based on the block ID, it is determined when to downgrade the stream ID. The solid-state hard disk described in item 6 of the scope of patent application, wherein: the downgrade logic includes: a comparator for determining whether the expiration time of the block ID has passed; When the expiration time has passed, a decrementer used to decrement the stream ID; and the second queuer is operative to respond to the decrement of the block ID The block ID is placed in the second queue of the plurality of queues corresponding to the plurality of stream IDs. A non-transitory storage medium, the non-transitory storage medium stores instructions. When the instructions are executed by a machine, a receiver receives a write command for a solid state drive (SSD), and the write command includes Logical block address (LBA); the LBA mapper maps the LBA to a block identifier (ID); the stream selection logic uses the block-to-stream mapper stored in the memory of the host computer system, The stream ID is selected based on the block ID; the stream ID adder adds the stream ID to the write command; the queuer stores the block ID in the memory And the background logic removes the block ID from the commit queue and updates the block to the stream mapper. The non-transitory storage medium described in claim 8, wherein the block-to-stream mapper includes a sequence, frequency, and recency (SFR) table, and the SFR table includes the block ID and target The stream ID of the block ID. The non-transitory storage medium according to claim 9, wherein the background logic includes sequential logic for selecting the previous stream ID when the LBA continues the second LBA of the previous write command. The non-transitory storage medium according to claim 9, wherein the background logic includes: recency logic to be based on the current access time for the block ID, and for the previous Access time and decay period to calculate recency weight; An access count adjuster for adjusting the access count of the block ID based on the recency weight to generate an adjusted access count; and a stream ID adjuster for adjusting the access count for the block ID based on The adjusted access count of to adjust the stream ID. The non-transitory storage medium as described in claim 8, wherein the block-to-stream mapper includes a node input item, and the node input item includes the block ID and information for the block ID The stream ID. The non-transitory storage medium described in claim 12, wherein the background logic includes: promotion logic for determining when to promote the stream ID based on the block ID; a second queuer, In response to the stream ID for the block ID, placing the block ID in the first queue of the plurality of queues corresponding to the plurality of stream IDs; and the downgrade logic, It is used to determine when to downgrade the stream ID based on the block ID. The non-transitory storage medium as described in item 13 of the scope of patent application, wherein: the downgrade logic includes: a comparator for determining whether the expiration time of the block ID has passed; and in the block ID When the expiration time of the block ID has passed, a decrementer used to decrement the stream ID; and the second queuer is operative to respond to the decrement of the block ID The stream ID, the block ID is placed in the corresponding to the plurality of stream ID In the second queue of the plurality of queues. A method for operating a solid state drive (SSD), which includes: receiving a write command from a software source; determining a logical block address (LBA) in the write command; identifying that the solid state drive (SSD) contains the The block identifier (ID) of the block of the LBA; access the stream ID associated with the block ID; assign the stream ID to the write command; process on the solid state drive The write command using the specified stream ID; and the background update of the stream ID associated with the block ID is performed. The method described in item 15 of the scope of patent application further includes: determining whether the logical block address is connected to the second LBA in the second write command; and connecting the second LBA in the logical block address In the case of the second LBA in the write command: determine the second stream ID assigned to the second write command; and assign the second stream ID to the write command. The method according to claim 15, wherein performing the background update of the stream ID associated with the block ID includes: adding the block ID to a submission queue; and in the area When the block ID is at the top of the submission queue, the block ID is removed from the submission queue. The method described in item 15 of the scope of the patent application, wherein the implementation is The background update of the stream ID associated with the block ID includes: increasing the access count of the block ID; calculating the zone in response to the current access time and the previous access time of the block ID The recency weight of the block ID; the access count of the block ID is updated in response to the recency weight; and the access count for the block ID is determined in response to the updated access count Stream ID. The method according to claim 15, wherein performing background update of the stream ID associated with the block ID includes: placing the block ID in the corresponding stream ID In the queue, the queue corresponding to the stream ID is one of a plurality of queues; and when the block ID reaches the top of the queue, it is determined whether to transfer the block ID is downgraded. The method according to claim 19, wherein: performing the background update of the stream ID associated with the block ID further includes determining the block ID in response to the access count and device lifetime Expiration time; and when the block ID reaches the top of the queue, it is determined whether to include the block ID in a downgrade; in the case that the expiration time of the block ID has passed: self-correspondence Remove the block ID from the queue of the stream ID; decrement the stream ID; and place the block ID in the second corresponding to the decremented stream ID In the queue.

Images