System, storage device and method supporting multiple modes for access

Abstract

This invention discloses a system supporting multiple access modes. The system may include a processor and memory coupled to the processor. A storage device may also be coupled to the processor. The storage device may include a first interface and a second interface. The storage device can be configured to expand memory. A mode switch can select a chosen interface from the first and second interfaces based on commands issued by the processor.

Description

Technical Field

[0001] This disclosure generally relates to storage devices, and more particularly, to storage devices that support multiple access modes. [Related Application Data]

[0002] This application claims the benefit of U.S. Provisional Patent Application Serial No. 63 / 240,363, filed on September 2, 2021, which is incorporated herein by reference for all purposes.

[0003] This application is related to U.S. Patent Application No. 17 / 511,540, filed on October 26, 2021, which claims the benefit of U.S. Provisional Patent Application Serial No. 63 / 222,406, filed on July 15, 2021, both of which are incorporated herein by reference for all purposes. Background Art

[0004] Sometimes, a machine may require additional memory for operation. While adding ordinary memory (usually Dynamic Random Access Memory (DRAM)) is an option, DRAM can be expensive. Other types of storage can be used to expand memory, trading off performance for cost. However, the techniques for accessing such other types of storage may limit the ways in which the storage can be used, thereby reducing its utility.

[0005] There is still a need to support expanded memory while reducing the performance cost. Summary of the Invention

[0006] Embodiments of this disclosure include the ability to route commands to a compute storage unit. When a command is received, the command router can determine whether the command is a command to be processed by the storage device or the compute storage unit. The command can then be directed to the storage device or the compute storage unit. Brief Description of the Drawings

[0007] The drawings described below are examples of how embodiments of this disclosure can be implemented and are not intended to limit the embodiments of this disclosure. Individual embodiments of this disclosure may include elements not shown in a particular drawing, and / or may omit elements shown in a particular drawing. The drawings are intended to provide illustration and may not be drawn to scale. FIG. 1 illustrates a machine that includes a storage device that can be used to expand memory, according to an embodiment of this disclosure. Figure 2 shows details of the machine of FIG. 1 according to an embodiment of the present disclosure. Figure 3 shows that the processor of FIG. 1 communicates with the storage device of FIG. 1 in two modes according to an embodiment of the present disclosure. Figure 4 shows that the operating system in the machine of FIG. 1 communicates with the storage device of FIG. 1 in two modes according to an embodiment of the present disclosure. Figure 5 shows a Solid State Drive (SSD) for expanding the memory of FIG. 1 according to an embodiment of the present disclosure. Figure 6A shows a flowchart of an example procedure for the operating system of FIG. 4 to switch between modes of communicating with the storage device of FIG. 1 according to an embodiment of the present disclosure. Figure 6B continues the flowchart of FIG. 6A for the operating system of FIG. 4 to switch between modes of communicating with the storage device of FIG. 1 according to an embodiment of the present disclosure. Figure 7 shows a flowchart of an example procedure for the storage device of FIG. 1 to receive commands in two modes according to an embodiment of the present disclosure. Figure 8A shows a flowchart of an alternative example procedure for the storage device of FIG. 1 to receive commands in two modes according to an embodiment of the present disclosure. Figure 8B continues the flowchart of FIG. 8A for the storage device of FIG. 1 to receive commands in two modes according to an embodiment of the present disclosure. Figure 9 shows a flowchart of an example procedure for the operating system of FIG. 4 to send commands to the storage device of FIG. 1 in two modes according to an embodiment of the present disclosure. Figure 10 shows a flowchart of an alternative example procedure for the operating system of FIG. 4 to send commands to the storage device of FIG. 1 in two modes according to an embodiment of the present disclosure. Embodiments

[0008] Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it should be understood that those of ordinary skill in the art may practice the present disclosure without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0009] 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, without departing from the scope of the present disclosure, a first module may be referred to as a second module, and similarly, a second module may be referred to as a first module.

[0010] The terms used in the description of the present disclosure herein are for the purpose of describing particular embodiments only and are not intended to limit the present disclosure. As used in the description of the present disclosure and the appended claims, unless the context clearly indicates otherwise, the singular forms "a / an" and "the" are also intended to include the plural forms. It should 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 "comprises / comprising", when used in this specification, specifies the presence of the stated features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. The components and features of the drawings are not necessarily drawn to scale.

[0011] Sometimes, a machine may require additional memory for operation. While adding memory (usually dynamic random access memory (DRAM)) is an option, DRAM can be expensive. Other types of storage can be used to expand memory, trading performance for cost. However, the technology for accessing such other types of storage may limit the ways in which the storage can be used, thus reducing its utility.

[0012] Using a storage device such as a solid state drive (SSD) to expand the memory in a machine can increase the storage by a significant amount at a cost lower than that of an equivalent amount of memory. For example, the average cost of a 64 gigabyte (GB) DRAM module can be about $350.00, or about $5.47 per GB. On the other hand, a 1 terabyte (TB) SSD can cost about $50.00, or about $0.05 per GB. Thus, while DRAM may be faster than an SSD, the cost per GB of DRAM can be approximately 100 times that of an SSD. Therefore, the cost savings of using an SSD can offset the fact that an SSD may be slower to access than DRAM.

[0013] However, since an SSD can be designed to store a large amount of data, an SSD can also be designed to support reading and writing a large amount of data at once. For example, while a command to load data from memory or store data to memory may read or write only, say, 64 bytes per command, an SSD read or write command can process data in chunks of, say, 4 kilobytes (KB). However, the host processor may not know that the storage is an SSD and may attempt to access the storage as if it were memory. Thus, when using an SSD as a typical storage device, accessing a large amount of data from the storage in the SSD as if it were memory may take longer than accessing a comparable amount of data from the storage in the SSD.

[0014] Embodiments of the present disclosure can overcome these problems by using two interfaces to an SSD that is being used to expand memory in a machine. For small amounts of data, conventional load / store commands can be used. However, when accessing a large amount of data from storage, and in particular when writing a large amount of data to storage, a write command can be used to access the SSD. Since a write command can support a larger amount of data than a store command, using a write command can write data to storage more efficiently than using a store command. The operating system can determine which mode to use when storing / writing data to storage.

[0015] FIG. 1 illustrates a machine that includes a storage device that can be used to expand memory, in accordance with an embodiment of the present disclosure. In FIG. 1, a machine 105 (which may also be referred to as a host or a system) can include a processor 110, a memory 115, and a storage device 120. The processor 110 can be any kind of processor. (For ease of illustration, the processor 110 and other components discussed below are shown outside the machine: embodiments of the present disclosure can include such components within the machine.) Although FIG. 1 shows a single processor 110, the machine 105 can include any number of processors, each of which can be a single-core processor or a multi-core processor, each of which can implement a Reduced Instruction Set Computer (RISC) architecture or a Complex Instruction Set Computer (CISC) architecture (and other possible architectures), and can be mixed in any desired combination.

[0016] Processor 110 may be coupled to memory 115. Memory 115 may be any kind of memory, such as flash memory, dynamic random access memory (DRAM), static random access memory (SRAM), persistent random access memory, ferroelectric random access memory (FRAM), or non-volatile random access memory (NVRAM), such as magnetoresistive random access memory (MRAM), etc. Memory 115 may also be any desired combination of different memory types and may be managed by memory controller 125. Memory 115 may be used to store data that may be referred to as "short-term": that is, data that is not expected to be stored for a long period of time. Examples of short-term data may include temporary files, data used locally by an application program (which may have been copied from other storage locations), and the like.

[0017] Processor 110 and memory 115 may also support an operating system that may be running various application programs. These application programs may issue requests (also referred to as commands) to read data from or write data to any of memory 115. When storage device 120 is used to support application programs that read or write data via a certain file system, device driver 130 may be used to access storage device 120. However, when storage device 120 is used to expand memory 115, processor 110 may issue commands to load and / or store data as if storage device 120 were additional memory 115. In such embodiments of the present disclosure, the storage provided by storage device 120 may be used by processor 110 as if storage device 120 itself were memory 115, even though storage device 120 may use a different physical structure and different access mechanisms than memory 115. In the remainder of this document, unless the context otherwise implies, it should be understood that storage device 120 is being used to expand memory 115 and may not be used by application programs to store and retrieve data (files, objects, or other data types) as a storage device for more traditional purposes.

[0018] In an embodiment of the present disclosure where the storage device 120 is used to expand the memory 115, a cache coherent interconnect protocol such as the Compute Express Link® (CXL) protocol or the Peripheral Component Interconnect Express (PCIe) protocol can be used to expand the memory 115 using the storage device 120. (Compute Express Link is a registered trademark of the Compute Express Link Consortium, Inc.) In an embodiment of the present disclosure, the connection 135 can be used to enable the processor 110 to communicate with the storage device 120. However, embodiments of the present disclosure can also enable access to the storage device 120 via an interface such as a PCIe interface via other mechanisms such as the device driver 130.

[0019] Although FIG. 1 depicts one storage device 120, any number (one or more) of storage devices can be present in the machine 105.

[0020] Although FIG. 1 uses the general term "storage device", embodiments of the present disclosure can include any storage device format that can benefit from the use of a compute storage unit, examples of which can include hard disk drives and solid state drives (SSDs). Any reference to "SSD" hereinafter should be understood to include such other embodiments of the present disclosure. Additionally, although the discussion above (and below) focuses on the storage device 120 as associated with a compute storage unit, embodiments of the present disclosure can extend to devices other than those that can include or be associated with a compute storage unit. Any reference to "storage device" above (and below) can be understood to also encompass other devices that may be associated with a compute storage unit.

[0021] FIG. 2 illustrates details of the machine 105 of FIG. 1 according to an embodiment of the present disclosure. In FIG. 2, generally, the machine 105 includes one or more processors 110, which may include a memory controller 120 and a clock 205, which can be used to coordinate the operation of the components of the machine. The processor 110 may also be coupled to a memory 115, which, as an example, may include random access memory (RAM), read-only memory (ROM), or other state-retention media. The processor 110 may also be coupled to a storage device 125 and a network connector 210, which may be, for example, an Ethernet connector or a wireless connector. The processor 110 may also be connected to a bus 215, to which a user interface 220 and input / output (I / O) interface ports that can be managed using an input / output (I / O) engine 225, as well as other components, may be attached.

[0022] FIG. 3 illustrates that the processor 110 of FIG. 1 communicates with the storage device 120 of FIG. 1 using two modes according to an embodiment of the present disclosure. In FIG. 3, in one mode, the processor 110 may communicate with the storage device 120 using mode 305. In mode 305, the storage device 120 may include a host-managed device memory (HDM) 310. The processor 110 may access the HDM 310 in the same manner as the memory 115 of FIG. 1: the processor 110 may issue load and store commands (denoted as commands 315) to read data from the HDM 310 and write data to the HDM 310. From the perspective of the processor 110, the HDM 310 may be considered as another memory module similar to the memory 115. The underlying data may actually be stored in a storage 320, where the HDM 310 acts as a “front end” for the processor 110 to access the data.

[0023] In an extended memory system, the processor 110 can use a range of addresses, some of which can be in the memory 115 of FIG. 1 and some of which can be in the storage device 120. For example, consider the case where the memory 115 of FIG. 1 contains eight gigabytes (GB) of memory and the storage device 120 contains eight gigabytes of storage. The processor 110 can use addresses 0x00000000 to 0x1FFFFFFF to access data in the memory 115 of FIG. 1, and use addresses 0x20000000 to 0x3FFFFFFF to access data in the storage device 120. As far as the processor 110 is concerned, the machine 105 of FIG. 1 provides 16 gigabytes of memory that can be accessed via addresses 0x00000000 to 0x3FFFFFFF: the processor 110 may not care what form of storage is used to provide this 16 gigabyte memory. However, given a specific address, virtual memory management may know where the requested data actually resides.

[0024] When the processor 110 issues a request to access a specific address, this address is called a "physical address". For data stored in the memory 115 of FIG. 1, this term is reasonable: the data located at an address (such as 0x000001000) can be at the actual physical address in the memory 115 of FIG. 1. However, for data stored on the storage device 120, the term "physical address" may not be descriptive. For example, some storage devices such as solid state drives (SSDs) can use a translation layer to map a specific address as used by the processor 110 to the address where the data is actually stored. In this way, as further discussed with reference to FIG. 5 below, such storage devices can relocate data as needed without having to notify the processor 110 of the new address where the data is stored. Therefore, context can be important when understanding whether the term "physical address" refers to the actual physical location on the storage device 120 where the data is stored or just some other logical identifier of where the data is stored on the storage device 120, where the storage device 120 handles the mapping from the "physical address" used by the processor 110 to the actual storage location of the data on the storage device 120.

[0025] In addition to these operations, virtual memory management can also manage page tables. Page tables allow applications to use virtual addresses that can be mapped to physical addresses. For each piece of data used by an application, there can be an entry in the page table that associates the virtual address used by the application with a physical address in the extended memory system where the data is stored (at least from the perspective of the processor 110). In this way, two or more applications can use the same virtual address that can be mapped to different physical addresses, which can prevent two applications from accessing the same data. (Of course, if an application wants to share data, its corresponding page table can map the virtual address to the same physical address.)

[0026] However, there can be some complications when using the storage device 120 to expand the memory 115 of FIG. 1. One complication can be the size of the storage device 120 itself and whether the entire storage device 120 is exposed to the processor 110. In some embodiments of the present disclosure, the size of the HDM 310 can be equal to the storage 320 provided by the storage device 120. In other embodiments of the present disclosure, the storage 320 can be larger than the HDM 310. For example, the storage 320 can be approximately 10 times larger than the HDM 310.

[0027] In some embodiments of the present disclosure where the storage 320 is larger than the HDM 310, the HDM 310 can be mapped to a specific set of addresses in the storage 320. The processor 110 may not be able to access the data at addresses that are not mapped to addresses in the HDM 310. In such embodiments of the present disclosure, a larger space in the storage 320 may be lost, and the storage device 120 may appear to provide only as much storage as the HDM 310 provides.

[0028] In other embodiments of the present disclosure where the storage 320 is larger than the HDM 310, the processor 110 may still be able to access any data from the storage 320. For example, consider a case where the HDM 310 contains 10 gigabytes and the storage 320 contains 20 gigabytes. If the processor 110 attempts to access an address outside the set of addresses currently supported by the HDM 310, the storage device 120 can flush (i.e., write) any data from the HDM 310 to the storage 320 and then load another 10 gigabytes of data from the storage 320 into the HDM 310.

[0029] Another complex situation may be the access unit for the data on the storage device 120. For example, the memory 115 of FIG. 1 is typically byte-addressable: the processor 110 may attempt to read or write individual bytes within the memory 115 of FIG. 1. However, the storage device 120 may not be byte-addressable. For example, an SSD typically writes or reads in units of pages or blocks. The size of a page may be, for example, about 4 kilobytes or 8 kilobytes (although other page sizes may also be used). A block may contain, for example, 128 pages or 256 pages (although a block may contain other numbers of pages). Thus, the size of a block may be many KB or MB: for example, a block containing 256 4-kilobyte pages may each contain 1 megabyte of storage. Reading or writing 1 megabyte of data just to access a single byte may be inefficient.

[0030] To address this issue, the storage device 120 may include a buffer 325. The buffer 325 may be a module such as a DRAM module (similar to the modules that may constitute the memory 115 of FIG. 1). The HDM 310 may support byte-addressable access to the buffer 325. The storage device 120 may then load and refresh the data between the storage 320 and the buffer 325 as needed. Thus, when the processor 110 attempts to access an address in the storage 320 that maps to an address that is not currently loaded in the buffer 325 via the HDM, the storage device 120 may write any changed data in the buffer 325 to the storage 320, and then load a new portion of the storage 320 into the buffer 325 so that the processor 110 can access the data via the HDM 310.

[0031] A third complex situation when using the storage device 120 to expand the memory 115 of FIG. 1 may be the basic unit of access. For example, when the processor 110 accesses the memory 115 of FIG. 1, the processor 110 may load and store data in units of, say, 64 bytes (which may be the size of a cache line). However, as discussed above, the storage device 120 may use pages or blocks as the basic unit of access, which may be larger (potentially, orders of magnitude larger) than the size of the basic unit of accessing the memory 115 of FIG. 1.

[0032] Although accessing storage device 120 using a smaller access unit may not be harmful (storage device 120, via HDM 310 and buffer 325, can use a smaller-sized access unit to manage access to data), using a smaller access unit may be inefficient, especially in the case of transferring large amounts of data. For example, sending data worth 4 kilobytes (which could be the size of a page) using 64 bytes (the basic unit of access for memory 115) at a time may involve 64 load or store commands, whereas a single native command for storage device 120 can enable the transfer of that amount of data.

[0033] To address this complexity, processor 110 can also communicate with storage device 120 using mode 330. In mode 330, storage device 120 can issue direct memory access (DMA) commands such as command 335 to storage device 120. These commands can access data using the set of native commands supported by storage device 120, such as an application that attempts to access a file via the file system. To transfer larger amounts of data between processor 110 and storage 320, using native commands may be more efficient and can result in a 30% improvement in accessing storage device 120 (at least for bulk data access).

[0034] In some embodiments of the present disclosure, command 335 can include any native command supported by storage device 120. In other embodiments of the present disclosure, command 335 may be restricted to write commands. In such embodiments of the present disclosure, requests to access data from storage 320 can be handled via command 315 in mode 305. The reason for not using mode 330 to handle data read operations may be to ensure data consistency: if data is read via mode 330, information about which data may need to be written back to storage 320 (e.g., from the write-back cache in processor 110) may be lost, which could ultimately result in data loss. In the remainder of this document, commands 335 issued via mode 330 may be restricted to commands that write data to storage 320 (without reading data from storage 320). However, embodiments of the present disclosure can include command 335 that includes commands to read data from storage 320, provided that consistency and synchronization issues can be resolved in other ways.

[0035] FIG. 4 illustrates an operating system in machine 105 of FIG. 1 communicating with storage device 120 of FIG. 1 using two modes according to an embodiment of the present disclosure. In FIG. 4, application 405 can communicate with operating system 410, which in turn can communicate with storage device 120.

[0036] The application 405 can issue commands to access data from the storage device 120, such as commands 315 and 335 in FIG. 3. The application 405 can issue a write command 415 to write data to the storage device 120. It should be noted that in this case, the application 405 can be aware that the storage device 120 is acting to expand the memory 115 in FIG. 1, but can issue appropriate commands to perform page (or block) size write commands on the storage device 120. The write command 415 can be passed to the operating system 410, and the operating system 410 can provide a block mode 330. In the block mode 330, access to the data on the storage device 120 can be provided just like block access to any storage device. The operating system can enable access to files such as file 420, store the data from file 420 in the page cache 425, manage the data blocks in file 420 using block management 430 (which can identify using logical block addresses (LBAs) or other logical identifiers), and access the storage device 120 using the device driver 130, and send the write command 415 to the storage device 120 via the transmitter 435.

[0037] The storage device 120 can include an interface 440-1. The interface 440-1 can enable access to the storage device 120 using the block mode: for example, the commands received via the interface 440-1 can be expected to use the PCIe protocol and can be interpreted using the PCIe module 445.

[0038] As further discussed with reference to FIG. 5, hereinafter, when identifying the specific data requested from the storage device 120, the application 405 can use a logical identifier such as an LBA. This LBA can be an identifier within the LBA space 450. The storage device can map this LBA to a physical address, such as a physical block address (PBA) on the storage device 120, where the data is actually stored in the storage space 320. This mapping can be performed using, for example, a flash translation layer. In this way, the application 405 can reference the data without having to know exactly where the data is stored on the storage device 120, and if the data is relocated within the storage device 120, the identifier does not have to be updated.

[0039] On the other hand, the application can issue a load / store command 455 to read / write data from / to the memory 115 of FIG. 1 that can be extended by the storage device 120. The load / store command 455 can be passed to the operating system 410, and the operating system 410 can also provide a direct access for file (DAX) mode 305. The application 405 can perform memory mapping using mmap(), which enables byte-addressable access to data in the extended memory system. When the operating system 410 receives the load / store command 455, the operating system 410 can use the mode 305 of FIG. 3 to process the load / store command 455. In the mode 305 of FIG. 3, the operating system 410 can provide the command to the virtual memory management 460, and the virtual memory management 460 can then pass the command to the storage device 120. The virtual memory management 460 can verify the virtual address in the load / store command 455 and map the virtual address to a physical address. According to this physical address, the virtual memory management 460 can identify where the data is actually stored: for example, stored on the storage device 120 or the memory 115 of FIG. 1. Once the virtual memory management 460 has determined that the load / store command 455 should be directed to the storage device 120, the operating system 410 can then send the load / store command 455 to the storage device 120 via the transmitter 435. (If the virtual memory management 460 determines that the load / store command 455 should be directed to the memory 115, the load / store command 455 can take a different path than in the case where the load / store command 455 is sent to the storage device 120: the latter can travel across a bus such as the PCIe bus, while the former can travel across the memory bus, which may involve a different transmitter than the transmitter 435.)

[0040] The storage device 120 can include an interface 440-2. The interface 440-2 can enable access to the storage device 120 using the DAX mode: for example, commands received via the interface 440-2 can be expected to use the CXL.mem protocol and can be interpreted using the CXL.mem module 465. As discussed above with reference to FIG. 3, although the load / store command received at the interface 440-2 can use a physical address that may be within the physical address 470, this physical address can actually be another logical identifier of the data. The storage device 120 can then map the physical address 470 to the storage space 320 (depending on whether the physical address can be directly mapped, which may or may not use a flash translation layer). It should be noted that the storage space 320 is mapped to by both the physical address 470 and the LBA space 450.

[0041] HDM 310 and buffer 325 of FIG. 3 are not shown in FIG. 4. HDM 310 and buffer 325 of FIG. 3 can be included to support the use of CXL.mem module 465 and the mapping of physical address 470 to storage space 320.

[0042] The operating system can also determine that load / store command 455 (especially when the command is a store command 455) can be better handled using block mode access. In such embodiments of the present disclosure, the operating system 410 can use mode 330 of FIG. 3 to process load / store command 455. In mode 330 of FIG. 3, mode switch 475 can direct command 455 to be handled using block mode 330, even if the command is issued using DAX mode 305. Once the operating system 410 has directed command 455 to be handled using block mode 330, the command can be processed similarly as if application 405 had issued a write command 415.

[0043] It should be noted that using mode switch 475 can cause load / store command 455 to be processed as if it were a write command 415. Since the format of the command may be different, before processing command 455 using block mode 330, the operating system 480 can use modifier 480 to modify load / store command 455 into a format similar to write command 415 before processing the command using block mode 330. In this way, storage device 120 can identify and process the modified command. However, although mode switch 475 processes load / store command 455 as if it were a write command 415, as far as application 405 is concerned, application 405 is still accessing data in the extended memory system. Application 405 may not be aware that the data is stored in storage 320, or that the operating system 410 may ultimately use a write command to process load / store command 455.

[0044] There are various ways in which the operating system 410 can make a decision to handle store command 455 using block mode 330. One way for the operating system 410 to make a determination to handle store command 455 using block mode 330 can be based on the parameters of the operating system 410. For example, in some embodiments of the present disclosure, the operating system 410 can have a system-wide parameter (for use at least within the user space including application 405) that can indicate whether store command 455 should be handled using block mode 330. If this parameter is set, store command 455 can be handled using block mode 330; if this parameter is not set, store command 455 can be handled using DAX mode 305. Application 405 can then change this parameter as needed to specify whether store command 455 should be handled using block mode 330 or DAX mode 305.

[0045] In some embodiments of the present disclosure, a file (such as file 485) in the operating system 410 may contain values and / or attributes (such as properties associated with a file that are treated as metadata by the operating system 410), the values and / or attributes specifying whether to use block mode 330 or DAX mode 305 to process storage command 455: Application 405 may change this value and / or attribute in file 485 as needed to specify whether to use block mode 330 or DAX mode 305 to process storage command 455. When processing storage command 455 to make a determination, the operating system 410 may access this value from file 485 or this attribute of file 485 as needed. It should be noted that file 485 may contain multiple values and / or attributes, each of which may differently specify whether to use block mode 330 or DAX mode 305. For example, file 485 may contain values and / or attributes associated with each file being written to and / or read from, the values and / or attributes indicating the appropriate mode to be used to access data from the file.

[0046] In some embodiments of the present disclosure, the operating system 410 may determine the size of the data being accessed. If the size of the data being accessed meets a threshold value (e.g., if the number of blocks being written is greater than a certain threshold number), then the operating system 410 may use block mode 330 to process storage command 455; otherwise, the operating system 410 may use DAX mode 305 to process storage command 455.

[0047] In some embodiments of the present disclosure, an Application Programming Interface (API) is used to make a system call to change the mode to be used. For example, application 405 may use the API to change the attributes of file 485 to change the mode between block mode 330 and DXA mode 305. The API may also be used for other purposes.

[0048] In some embodiments of the present disclosure, the operating system 410 may use a combination of these methods to determine whether to use block mode 330 or DAX mode 305 to process a particular command 455. It should also be noted that the operating system 410 may also use command 455 itself as part of the determination process: for example, if a storage command can only be processed using block mode 330, then if command 455 is a load command, the operating system 410 may use DAX mode 305 to process command 455, regardless of any other parameters, attributes, values, or sizes that may suggest that command 455 should be processed using block mode 455.

[0049] Since the processor 110 in FIG. 1 may not be blocked while executing the write command 415, the processor 110 in FIG. 1 can execute other commands. However, if these other commands include load / store commands 455, the result may be data inconsistency. For example, consider the case where the write command 415 is being executed and a load command 455 is received. If the load command 455 requests the data that is being written by the pending write command 415, the loaded data may not be the data that will be written using the write command 415. To avoid this data inconsistency problem, in some embodiments of the present disclosure, the load command 455 can be blocked when the write command 415 is incomplete. In other embodiments of the present disclosure, the operating system 410 can determine whether the load command 455 is attempting to load the data that is being written by the write command 415, and can block the load command 455 only if the load command 455 is attempting to load the data that is being written by the write command 415. In some embodiments of the present disclosure, the operating system 410 can similarly block the store command 455 to avoid the possibility that both the write command 415 and the store command 455 attempt to write data to the same file, which may leave the data in the storage device 120 in an unknown state (e.g., written by the write command 415, written by the store command 455, or partially written by the write command 415 and partially written by the store command 455).

[0050] In the above description, only the load / store commands 455 are described as potentially being modified to use the block mode 330: it is assumed that the write command 415 is preferably handled by the block mode 330. However, embodiments of the present disclosure can also support converting block mode commands to DAX mode commands. For example, the operating system can receive the write command 415, determine that the amount of data being written is small enough that there is little benefit in using the block mode 330, and can instead modify the command to use the DAX mode 305. Similarly, the operating system 410 can receive a read command from the application 405 and can convert the read command into a load command to use the DAX mode. In this way, the application 405 can avoid the need to determine (or attempt to determine) the best mode for a particular command: the operating system 410 can make the determination, and the application 415 can issue a read command without having to worry about the data inconsistency that may result from using the read command.

[0051] FIG. 5 illustrates a solid state drive (SSD) for expanding the memory 115 of FIG. 1 according to an embodiment of the present disclosure. In FIG. 5, the SSD 120 may include interface 440-1 and interface 440-2. Interface 440-1 and interface 440-2 may be interfaces for connecting the SSD 120 to the machine 105 of FIG. 1. As illustrated, the SSD 120 may include more than one interface 440-1 and interface 440-2: for example, one interface may be used for block-based read and write requests, and another interface may be used for DAX mode read and write requests. Although FIG. 5 shows interface 440-1 and interface 440-2 as physical connections between the SSD 120 and the machine 105 of FIG. 1, interface 440-1 and interface 440-2 may also represent protocol differences that may be used across a common physical interface. For example, the SSD 120 may be connected to the machine 105 using a U.2 or M.2 connector, but may support block-based requests and DAX mode requests: handling different types of requests may be performed by different interfaces 440-1 and interface 440-2.

[0052] The SSD 120 may also include a host interface layer 505 that can manage interface 440-1 and interface 440-2. If the SSD 120 includes more than one interface 440-1 and interface 440-2, a single host interface layer 505 may manage all interfaces, the SSD 120 may include a host interface layer for each interface, or some combination thereof may be used.

[0053] The SSD 120 may also include an SSD controller 510, various channels 515-1, 515-2, 515-3, and 515-4, and various flash memory chips 320-1, 320-2, 320-3, 320-4, 320-5, 320-6, 320-7, and 320-8 (flash memory chips 320-1 to 320-8 may be collectively referred to as flash memory chips 320) that may be arranged along the channels. The SSD controller 510 may manage sending read requests and write requests along channels 515-1 to 515-4 (which may be collectively referred to as channels 515) to flash memory chips 320-1 to 320-8. Although FIG. 5 shows four channels and eight flash memory chips, embodiments of the present disclosure may include any number (one or more, without limitation) of channels that include any number (one or more, without limitation) of flash memory chips.

[0054] Within each flash memory chip, the space can be organized into blocks, which can be further subdivided into pages, and which can be grouped into superblocks. The page size can vary as needed: for example, a page can be 4 kilobytes of data. If less than an entire page is written, the extra space is "unused". A block can contain any number of pages: for example, 128 or 256. And a superblock can contain any number of blocks. A flash memory chip may not organize the data into superblocks, but only into blocks and pages.

[0055] Although pages can be written to and read from, an SSD generally does not permit overwriting of data: that is, existing data may not be replaced "in-place" with new data. Instead, when data is to be updated, the new data is written to a new page on the SSD, and the original page is invalidated (marked as ready to be erased). Thus, an SSD page typically has one of three states: idle (ready to be written), valid (containing valid data), and invalid (no longer containing valid data, but not usable until erased) (the exact names of these states may vary).

[0056] However, although pages can be written to and read from individually, a block is the basic unit of data that can be erased. That is, pages are not erased individually: typically all pages in a block are erased at the same time. For example, if a block contains 256 pages, then all 256 pages in the block are erased at the same time. <This configuration can lead to some management problems for an SSD: if a block that still contains some valid data is selected for erasure, then the valid data may need to be copied to an idle page elsewhere on the SSD before the block can be erased. (In some embodiments of this disclosure, the unit of erasure can be different from a block: for example, it can be a superblock, which, as discussed above, can be a collection of multiple blocks.)

[0057] Since the units for writing data and erasing data are different (pages and blocks), if the SSD waits until a block contains only invalid data before erasing the block, the SSD may run out of available storage space even though the amount of valid data may be less than the advertised capacity of the SSD. To avoid this situation, the SSD controller 510 may include a garbage collection controller (not shown in FIG. 5). The function of garbage collection can be to identify blocks that contain all or almost all invalid pages and release those blocks so that valid data can be written into them again. However, if the blocks selected for garbage collection contain valid data, the valid data will be erased by the garbage collection logic (because the unit being erased is a block, not a page). To avoid this data loss, the garbage collection logic can program the valid data from such blocks into other blocks. Once the data has been programmed into the new blocks (and the table mapping the LBAs to the physical block addresses (PBAs) is updated to reflect the new location of the data), the blocks can be erased, thereby returning the state of the pages in the blocks to the idle state.

[0058] Before the SSD can trust that a unit is correctly retaining data, the SSD also has a limited number of times that each unit can be written to. This number is typically measured as a count of the number of program / erase cycles that the unit has experienced. Generally, the number of program / erase cycles that a unit can support means that the SSD will maintain reliable functionality within a reasonable time frame: for individual users, it is more likely that the user will replace the SSD due to insufficient storage capacity than due to having exceeded the number of program / erase cycles. However, in an enterprise environment where data can be written and erased more frequently, the risk that a unit will exceed its program / erase cycle count can be more significant.

[0059] To help offset this risk, the SSD controller 510 can use a wear leveling controller (not shown in FIG. 5). Wear leveling can involve selecting data blocks to program data based on the program / erase cycle count of the blocks. By selecting blocks with a lower program / erase cycle count to program new data, the SSD may be able to avoid increasing the program / erase cycle count of some blocks beyond their reliable operating point. By keeping the wear level of each block as close as possible, the SSD can remain reliable over a longer time frame.

[0060] The SSD controller 510 may include a flash translation layer (FTL) 520 (which may be more generally referred to as a translation layer for storage devices that do not use flash storage devices), an HDM 310, a buffer 325, and firmware 525. The FTL 520 may handle the translation of logical block addresses (LBAs) or other logical IDs (such as those used by the processor 110 of FIG. 1) to physical block addresses (PBAs) or other physical addresses where data is stored in flash chips 320-1 to 320-8. The FTL 520 may also be responsible for relocating data from one PBA to another PBA, as may occur when performing garbage collection and / or wear leveling. The HDM 310 and buffer 320 are discussed with reference to FIG. 3 above. The firmware 525 may be stored on a suitable hardware module (such as a programmable read-only memory PROM), an erasable PROM (EPROM), and an electrically erasable PROM (EEPROM) or some other variant thereof. The firmware 525 may be responsible for managing what data is in the buffer 325, and may flush data from the buffer 325 to the flash memory chips 320, and load data from the flash memory chips 320 into the buffer 325.

[0061] FIG. 6A illustrates a flowchart of an example procedure for the operating system 410 of FIG. 4 to switch between modes of communicating with the storage device 120 of FIG. 1 according to an embodiment of the present disclosure. In FIG. 6A, at block 605, the operating system 410 of FIG. 4 may switch to the block mode 330 of FIG. 3: for example, if the application 405 of FIG. 4 issues a write command 415 of FIG. 4, or if the operating system 410 of FIG. 4 determines that the storage command 455 of FIG. 4 should be processed using the block mode 330 of FIG. 3. At block 610, the operating system 410 of FIG. 4 may process the command as a write command 415 of FIG. 4 in the block mode 330 of FIG. 3.

[0062] At block 615, the operating system 410 of FIG. 4 may determine whether the application 405 of FIG. 4 has issued a load command 455 of FIG. 4 (or whether the operating system 410 of FIG. 4 determines that another storage command 455 of FIG. 4 should be processed using the DAX mode 305 of FIG. 3). If not, the process may return to block 610 to handle other write commands in the block mode 330 of FIG. 3.

[0063] However, if the application 405 in FIG. 4 issues a load command 455, or if the operating system 410 in FIG. 4 determines that the storage command 455 is to be handled using the DAX mode 305 of FIG. 3, then at block 620 (FIG. 6B), the operating system 410 of FIG. 4 can switch to the DAX mode 305 of FIG. 3. At block 625, the operating system 410 of FIG. 4 can map the file being loaded by the application 405 of FIG. 4. This process may involve determining one or more virtual addresses that can be used by the application 405 of FIG. 4 and the corresponding physical addresses in the extended memory system where the data is stored, and configuring the page table for the application 405 of FIG. 4 accordingly. At block 630, the operating system 410 of FIG. 4 can send the load / store command 455 of FIG. 4 to the storage device 120 of FIG. 1.

[0064] Finally, at block 635, the operating system 410 of FIG. 4 can determine whether the application 405 of FIG. 4 has issued a write command 415 of FIG. 4 (or whether the operating system 410 of FIG. 4 determines that another storage command 455 of FIG. 4 is to be processed using the block mode 330 of FIG. 3). If not, the process can return to block 630 to handle other load / store commands in the DAX mode 305 of FIG. 3. Otherwise, the process can return to block 605 of FIG. 6A to handle the write command in the block mode 330 of FIG. 3.

[0065] FIG. 7 illustrates a flowchart of an example procedure for the storage device 120 of FIG. 1 to receive commands using two modes according to an embodiment of the present disclosure. In FIG. 7, at block 705, the storage device 120 of FIG. 1 can receive the command 455 of FIG. 4 via the interface 440-2 of FIG. 4. At block 710, the controller 510 of FIG. 5 can process the command 455 of FIG. 4. At block 715, the storage device 120 of FIG. 1 can receive the command 415 of FIG. 4 via the interface 440-1 of FIG. 4. At block 720, the controller 510 of FIG. 5 can process the command 415 of FIG. 4.

[0066] FIG. 8A illustrates a flowchart of an alternative example procedure for the storage device 120 of FIG. 1 to receive commands using two modes according to an embodiment of the present disclosure. In FIG. 8A, at block 805, the storage device 120 of FIG. 1 can authorize the processor 110 of FIG. 1 to access the HDM 310 of FIG. 3. At block 810, the storage device 120 of FIG. 1 can manage the HDM 310 of FIG. 3 using the buffer 325 of FIG. 3. This management may include the firmware 525 of FIG. 5 that manages the data consistency between the buffer 325 of FIG. 3 and the memory 320 of FIG. 3.

[0067] At block 815, the storage device 120 of FIG. 1 may receive the command 455 of FIG. 4 via the interface 440-2 of FIG. 4. At block 820, the storage device 120 of FIG. 1 may process the command 455 of FIG. 4 using the controller 510 of FIG. 5. For example, the controller 510 of FIG. 5 may perform load / store operations on the buffer 325 of FIG. 1 and may also write data to or read data from the memory 320 of FIG. 3.

[0068] At block 825 (FIG. 8B), the storage device 120 of FIG. 1 may receive the command 415 of FIG. 4 via the interface 440-1 of FIG. 4. At block 830, the storage device 120 of FIG. 1 may process the command 415 of FIG. 4 using the controller 510 of FIG. 5. For example, the controller 510 of FIG. 5 may execute a command to write data to the memory 320 of FIG. 3.

[0069] Since the write command 415 of FIG. 4 may update the data stored in the buffer 325 of FIG. 3, at block 835, the storage device 120 of FIG. 1 may flush the buffer 325 of FIG. 3 to ensure that any updated data in the buffer 325 of FIG. 3 is written to the memory 320 of FIG. 3. At block 840, the storage device 120 of FIG. 1 may reload the buffer 325 of FIG. 3 with data from the memory 320 of FIG. 3. Finally, at block 845, since the buffer 325 of FIG. 3 may have been updated with new data, the storage device 120 of FIG. 1 may remap the HDM 310 of FIG. 3 to the buffer 325 of FIG. 3 to reflect the updated data, especially in the case where the size of the file is changed.

[0070] FIG. 9 illustrates a flowchart of an example procedure for an operating system 410 of FIG. 4 to send commands to a storage device 120 of FIG. 1 using two modes. In FIG. 9, at block 905, the operating system 410 of FIG. 4 may receive a command 415 of FIG. 4 or a command 455 of FIG. 4 from a processor 110 of FIG. 1. At block 910, the operating system 410 of FIG. 4 may determine whether to use the block mode 330 of FIG. 3 or the DAX mode 305 of FIG. 3 to handle the command 415 of FIG. 4 or the command 455 of FIG. 4. In block 915, the operating system 410 of FIG. 4 may then select an interface 440-1 or an interface 440-2 of FIG. 4 of the storage device 120 of FIG. 1. The selection of the interface 440-1 or the interface 440-2 of FIG. 4 may depend on the command 415 of FIG. 4 or the command 455 of FIG. 4, as well as other possible information. For example, as discussed above with reference to FIG. 4, if an application 405 of FIG. 4 issues a write command 415, the block mode 330 of FIG. 3 may be used, which may result in the selection of the interface 440-1 of FIG. 4; if the application 405 of FIG. 4 issues a load / store command 455, depending on a mode switch 475 of FIG. 4, the block mode 330 of FIG. 3 or the block mode 305 of FIG. 3 may be used, which may result in the selection of the interface 440-1 of FIG. 4 or the interface 440-2 of FIG. 4.

[0071] FIG. 10 illustrates a flowchart of an alternative example procedure for the operating system 410 of FIG. 4 to send commands to the storage device 120 of FIG. 1 using two modes according to an embodiment of the present disclosure. In FIG. 10, at block 1005, the operating system 410 of FIG. 4 may receive the command 415 of FIG. 4 or the command 455 of FIG. 4 from the processor 110 of FIG. 1. At block 1010, the operating system 410 of FIG. 4 may determine whether the command 415 of FIG. 4 or the command 455 of FIG. 4 accesses data from the storage device 120 of FIG. 1 (e.g., the command may be a command that can be processed within the operating system 410 of FIG. 4 and does not access data from the storage device 120 of FIG. 1). In block 1015, the operating system 410 of FIG. 4 may then select the interface 440-1 or the interface 440-2 of the storage device 120 of FIG. 1. The selection of the interface 440-1 or the interface 440-2 of FIG. 4 may depend on the command 415 of FIG. 4 or the command 455 of FIG. 4, as well as other possible information. At block 1020, the modifier 480 of FIG. 4 may modify the command 455 of FIG. 4 to be in a format similar to the command 415 of FIG. 4. For example, the modifier 480 of FIG. 4 may replace the command name of the command 455 of FIG. 4 with the command name of the command 415 of FIG. 4, and may replace the physical address of the command 455 of FIG. 4 with the LBA associated with the data expected to be written to the storage device 120 such as FIG. 1. The modifier 480 of FIG. 7 may also modify the reordering parameters in the command, and may modify the way of packing (e.g., encapsulating) the command and data for transmission to the storage device 120 of FIG. 1. Block 1020 may be omitted, as illustrated by the dashed line 1025. Finally, at block 1030, the transmitter 435 of FIG. 4 may transmit the command (modified or unmodified) to the selected interface 440-1 or the interface 440-2 of FIG. 4.

[0072] In FIGS. 6A to 10, some embodiments of the present disclosure are illustrated. However, those of ordinary skill in the art will recognize that other embodiments of the present disclosure are also possible by changing the order of the blocks, by omitting blocks, or by including links not illustrated in the drawings. All such variations of the flowchart are considered embodiments of the present disclosure, whether or not explicitly described.

[0073] When listing devices, a dual-mode solid-state drive (SSD) may support host-managed device memory (HDM) memory (i.e., the memory of the dual-mode SSD that the host central processing unit (CPU) can access via the CXL.mem protocol) registration. For example, if the dual-mode SSD is configured (in the device firmware) to define 250 gigabytes of HDM, the host CPU can see 250 gigabytes of memory in the device.

[0074] The dual-mode SSD can support memory access via CXL.mem and can support a DMA engine for CXL.io.

[0075] The dual-mode SSD can be designed to support two modes: a memory access mode and a storage access mode. The memory access mode can support CXL.mem, and the storage access mode can support Peripheral Component Interconnect Express (PCIe). CXL.io can be used to access control registers and the CXL configuration space.

[0076] The device driver can support an integrated device driver for both Non-Volatile Memory Express (NVMe) and the CXL protocol.

[0077] In the fsdax mode using a Non-Volatile Dual In-Line Memory Module (NVDIMM), the SSD can support two modes: a block mode and a dax mode. The block mode can enable read() and write() on direct memory access (DMA) via PCIe. The DAX mode can enable load / store via CXL.mem by the CPU. Since two device access paths are maintained, this method may have some data consistency issues. To avoid consistency issues, the SSD can include some principles for the file system and memory access. The dual-mode SSD may not permit "read()" via PCIe.

[0078] The application can create a file and can set its mode. If the application sets the file to the block mode, the write() operation can be completed by the page cache on the file system, and the actual data transfer can be completed via the NVMe device driver by DMA. If the application sets the file to the dax mode, the application can call mmap() and can submit load / store commands via CXL.mem.

[0079] The file system can maintain metadata and should track changes on files. If a file changes from CXL.mem, the metadata may be corrupted. To avoid this problem: (i) when the total number of block changes in a given file exceeds a threshold, the application can "write" in block mode; (ii) the application can only "load" and "store" in dax mode; (iii) "store" in dax mode can only be used for mapped pages: the SSD may not allow additional pages to be mapped via CXL.mem for "store"; (iv) when "writing" in block mode changes the size of the file, it may be necessary to remap in dax mode; and (v) when the "write" of PCIe is not completed, the "load" of CXL.mem may not be allowed.

[0080] The dual-mode SSD can operate as a memory device rather than a storage device.

[0081] The dual-mode SSD can provide a huge memory expansion (equivalent to the SSD capacity), with lower performance compared to DRAM. This trade-off may be effective for some applications with limited memory size.

[0082] The reason for maintaining the dual mode is that a large amount of data transfer via DMA (direct memory access) may be faster than writing via CXL.mem (memory access mode).

[0083] Software can use NVDIMM to support the application programming interface (API) on fsdax.

[0084] Embodiments of the present disclosure include a storage device that can support dual-mode access. If a command sent to the storage device can be better served using block-mode access, the command can be sent as a block-mode command. If a command sent to the storage device can be better served using DAX mode, the command can be sent as a DAX mode command. The operating system can determine the best mode of the command based on the command itself, operating system parameters, file values, file attributes, or the size of the accessed data. Once the operating system has determined the best mode, the operating system can select the appropriate interface on the dual-mode storage device, and the command can be passed to the dual-mode storage device.

[0085] The following discussion is intended to provide a brief general description of one or more suitable machines in which certain aspects of the present disclosure may be implemented. One or more machines may be controlled at least in part by input from conventional input devices such as a keyboard, mouse, etc., and by interaction with guidance received from another machine, a virtual reality (VR) environment, biometric feedback, or other input signals. As used herein, the term "machine" is intended to broadly encompass a single machine, a virtual machine, or a system of machines, virtual machines, or co-operating devices coupled in communication. Exemplary machines include computing devices such as personal computers, workstations, servers, laptop computers, handheld devices, telephones, tablet computers, etc.; and transportation devices such as private or public transportation, e.g., cars, trains, taxis, etc.

[0086] One or more machines may include an embedded controller such as a programmable or non-programmable logic device or array, an application specific integrated circuit (ASIC), an embedded computer, a smart card, and the like. One or more machines may utilize one or more connections to one or more remote machines, such as via a network interface, a modem, or other communication coupling. Machines may be interconnected by means of physical and / or logical networks such as an intranet, the Internet, a local area network, a wide area network, etc. Those of ordinary skill in the art will appreciate that network communication may utilize a variety of wired and / or wireless short-range or long-range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth®, optical, infrared, cable, laser, etc.

[0087] Embodiments of the present disclosure may be described with reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc., which when accessed by a machine cause the machine to perform tasks or define abstract data types or low-level hardware contexts. The associated data may be stored, for example, in volatile memory and / or non-volatile memory (e.g., RAM, ROM, etc.), or in other storage devices and their associated storage media, including hard disk drives, floppy disks, optical storage, magnetic tape, flash memory, memory sticks, digital video disks, biological storage, etc. The associated data may be transmitted via a transmission environment, including physical and / or logical networks, in the form of packets, serial data, parallel data, propagated signals, etc., and the associated data may be used in a compressed or encrypted format. The associated data may be used in a distributed environment and stored locally and / or remotely for access by a machine.

[0088] Embodiments of the present disclosure may include a tangible non - transitory machine - readable medium that includes instructions executable by one or more processors, the instructions including instructions for performing the elements of the present disclosure as described herein.

[0089] The various operations of the methods described above may be performed by any suitable component capable of performing the operations, such as various hardware and / or software components, circuits, and / or modules. Software may include an ordered listing of executable instructions for implementing logical functions, and it may be embodied in any "processor - readable medium" for use by or in connection with an instruction - execution system, apparatus, or device, such as a single - core processor or multi - core processor or a system containing a processor.

[0090] Blocks or steps of a method or algorithm and the described functions in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. If implemented in software, the functions may be stored on or transmitted via a tangible non - transitory computer - readable medium as one or more instructions or code. Software modules may reside in random access memory (RAM), flash memory, read - only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disk, removable disk, CD ROM, or any other form of storage medium known in the art.

[0091] The principles of the present disclosure have been described and illustrated with reference to the described embodiments. It will be recognized that the described embodiments may be modified in configuration and detail without departing from such principles and may be combined in any desired manner. In addition, although the foregoing discussion has focused on specific embodiments, other configurations are encompassed. Specifically, although expressions such as "according to an embodiment of the present disclosure" or the like are used herein, such phrases generally refer to the possibility of reference to embodiments in general and are not intended to limit the present disclosure to a particular embodiment configuration. As used herein, such terms may refer to the same or different embodiments incorporated into other embodiments.

[0092] The foregoing exemplary embodiments should not be construed as limiting its disclosure. Although several embodiments have been described, those of ordinary skill in the art will readily appreciate that many modifications to those embodiments are possible without materially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the claims.

[0093] Embodiments of the present disclosure can be extended to, but are not limited to, the following statements: Statement 1. Embodiments of the present disclosure include a system comprising: A processor; A memory coupled to the processor; A storage device coupled to the processor, the storage device comprising a first interface and a second interface, the storage device being configured to expand the memory; and A mode switch for selecting a selected interface from the first interface and the second interface for a command issued by the processor. Statement 2. Embodiments of the present disclosure include the system as described in Statement 1, wherein the storage device comprises: A register for data; A controller for managing data in the register; wherein the controller is configured to process commands. Statement 3. Embodiments of the present disclosure include the system as described in Statement 2, wherein the storage device further comprises: A host management device memory (HDM); and A buffer mapped from the HDM, wherein the processor can access the HDM; and the buffer can store a copy of a portion of the register. Statement 4. Embodiments of the present disclosure include the system as described in Statement 1, wherein the storage device comprises a solid state drive (SSD). Statement 5. Embodiments of the present disclosure include the system as described in Statement 4, wherein the mode switch is configured to select one of the first interface and the second interface for a command issued by the processor based at least in part on one of parameters of an operating system, second data in a file, metadata of the file, or a type of the command, a data size associated with the command. Statement 6. Embodiments of the present disclosure include the system as described in Statement 4, further comprising a transmitter for transmitting a command to the SSD using the selected interface. Statement 7. Embodiments of the present disclosure include the system as described in Statement 6, further comprising a modifier for modifying the command based at least in part on the selected interface. Statement 8. Embodiments of the present disclosure include the system as described in Statement 7, wherein the modifier is configured to replace the command with a second command based at least in part on the selected interface, the second command being different from the command. Statement 9. An embodiment of the disclosure includes the system as described in Statement 7, wherein the modifier is configured to replace a first parameter of a command with a second parameter of the command based at least in part on a selected interface, and the second parameter is different from the first parameter. Statement 10. An embodiment of the disclosure includes the system as described in Statement 7, wherein the modifier is configured to change the encapsulation of a command based at least in part on a selected interface. Statement 11. An embodiment of the disclosure includes the system as described in Statement 4, wherein the first interface includes a cache coherence interconnect protocol. Statement 12. An embodiment of the disclosure includes the system as described in Statement 11, wherein the cache coherence interconnect protocol includes a Compute Express Link (CXL) protocol. Statement 13. An embodiment of the disclosure includes the system as described in Statement 4, wherein the second interface includes a block interface. Statement 14. An embodiment of the disclosure includes the system as described in Statement 13, wherein the block interface includes a Peripheral Component Interconnect Express (PCIe) interface. Statement 15. An embodiment of the disclosure includes a storage device, comprising: a memory for data; a controller for managing data in the memory; a first interface for receiving a first command from a processor; and a second interface for receiving a second command from a host processor, wherein the controller is configured to process the first command and the second command, and wherein the storage device extends memory. Statement 16. An embodiment of the disclosure includes the storage device as described in Statement 15, further comprising: a host device memory (HDM); and a buffer mapped from the HDM, wherein the processor can access the HDM; and the buffer can store a copy of a portion of the memory. Statement 17. An embodiment of the disclosure includes the storage device as described in Statement 16, further comprising a non-transitory storage medium including instructions for refreshing and reloading the buffer based at least in part on the storage device receiving the second command. Statement 18. An embodiment of the disclosure includes the storage device as described in Statement 15, wherein the storage device includes a solid state drive (SSD). Statement 19. An embodiment of the disclosure includes the storage device as described in Statement 18, wherein the first interface includes a cache coherence interconnect protocol. Statement 20. An embodiment of the disclosure includes the storage device as described in Statement 19, wherein the cache coherence interconnect protocol includes a Compute Express Link (CXL) protocol. Statement 21. An embodiment of the disclosure includes the storage device as described in Statement 18, wherein the second interface includes a block interface. Statement 22. An embodiment of the disclosure includes the storage device as described in Statement 21, wherein the block interface includes a Peripheral Component Interconnect Express (PCIe) interface. Statement 23. An embodiment of the disclosure includes the storage device as described in Statement 18, wherein the first command includes one of a load command or a store command. Statement 24. An embodiment of the disclosure includes the storage device as described in Statement 18, wherein the second command includes a write command. Statement 25. An embodiment of the disclosure includes the storage device as described in Statement 18, wherein the second command includes a read command. Statement 26. An embodiment of the disclosure includes a method, comprising: receiving, at an operating system, a command from a processor; determining that the command accesses data on a storage device, the storage device including a first interface and a second interface; and selecting a selected interface of the first interface or the second interface based at least in part on the command, wherein the storage device is configured to expand memory. Statement 27. An embodiment of the disclosure includes the method as described in Statement 26, wherein determining that the command accesses data on the storage device includes determining that the command accesses data on a solid state drive (SSD). Statement 28. An embodiment of the disclosure includes the method as described in Statement 27, wherein the first interface includes a cache coherence interconnect protocol. Statement 29. An embodiment of the disclosure includes the method as described in Statement 28, wherein the cache coherence interconnect protocol includes a Compute Express Link (CXL) protocol. Statement 30. An embodiment of the disclosure includes the method as described in Statement 27, wherein the second interface includes a block interface. Statement 31. An embodiment of the disclosure includes the method as described in Statement 30, wherein the block interface includes a Peripheral Component Interconnect Express (PCIe) interface. Statement 32. An embodiment of the disclosure includes the method as described in Statement 27, wherein determining that the command accesses data on the SSD includes determining that the command accesses a host device memory (HDM) of the SSD. Statement 33. An embodiment of the present disclosure includes the method as described in Statement 27, wherein selecting a selected interface from the first interface and the second interface based at least in part on the command includes selecting the selected interface from the first interface or the second interface based at least in part on one of a parameter of an operating system, second data in a file, metadata of the file, or a type of the command, a data size associated with the command. Statement 34. An embodiment of the present disclosure includes the method as described in Statement 27, further including transmitting the command to the SSD using the selected interface. Statement 35. An embodiment of the present disclosure includes the method as described in Statement 34, wherein transmitting the command to the SSD using the selected interface includes modifying the command based at least in part on the selected interface. Statement 36. An embodiment of the present disclosure includes the method as described in Statement 35, wherein modifying the command based at least in part on the selected interface includes replacing the command with a second command based at least in part on the selected interface, the second command being different from the command. Statement 37. An embodiment of the present disclosure includes the method as described in Statement 35, wherein modifying the command based at least in part on the selected interface includes replacing a first parameter of the command with a second parameter of the command based at least in part on the selected interface, the second parameter being different from the first parameter. Statement 38. An embodiment of the present disclosure includes the method as described in Statement 35, wherein modifying the command based at least in part on the selected interface includes changing a packaging of the command based at least in part on the selected interface. Statement 39. An embodiment of the present disclosure includes a method, including: receiving, at a storage device, a first command from a processor via a first interface; processing, at the storage device, the first command; receiving, at the storage device, a second command from the processor via a second interface; and processing, at the storage device, the second command. Statement 40. An embodiment of the present disclosure includes the method as described in Statement 39, wherein: receiving, at the storage device, the first command from the processor via the first interface includes receiving, at a solid state drive (SSD), the first command from the processor via the first interface; processing, at the storage device, the second command includes processing, at the SSD, the second command; receiving, at the storage device, the second command from the processor via the second interface includes receiving, at the SSD, the second command from the processor via the second interface; and processing, at the storage device, the second command includes processing, at the SSD, the second command. Statement 41. An embodiment of the disclosure includes the method as described in Statement 40, wherein the first interface includes a cache coherence interconnect protocol. Statement 42. An embodiment of the disclosure includes the method as described in Statement 41, wherein the cache coherence interconnect protocol includes a Compute Express Link (CXL) protocol. Statement 43. An embodiment of the disclosure includes the method as described in Statement 40, wherein the second interface includes a block interface. Statement 44. An embodiment of the disclosure includes the method as described in Statement 43, wherein the block interface includes a Peripheral Component Interconnect Express (PCIe) interface. Statement 45. An embodiment of the disclosure includes the method as described in Statement 40, wherein receiving the first command at the SSD via the first interface includes: Authorizing access to a host management device memory (HDM) in the SSD by a processor; and Managing the HDM to a buffer in the SSD. Statement 46. An embodiment of the disclosure includes the method as described in Statement 40, wherein the first command includes one of a load command or a store command. Statement 47. An embodiment of the disclosure includes the method as described in Statement 40, wherein receiving the second command at the SSD from the processor via the second interface includes: Flushing a buffer in the SSD; and Reloading the buffer. Statement 48. An embodiment of the disclosure includes the method as described in Statement 47, wherein receiving the second command at the SSD from the processor via the second interface further includes remapping an HDM in the SSD to the buffer. Statement 49. An embodiment of the disclosure includes the method as described in Statement 40, wherein the second command includes a write command. Statement 50. An embodiment of the disclosure includes the method as described in Statement 40, wherein the second command includes a read command. Statement 51. An embodiment of the disclosure includes an article including a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the following operations: Receiving a command from a processor at an operating system; Determining that the command accesses data on a storage device, the storage device including a first interface and a second interface; and Selecting a selected interface of the first interface or the second interface based at least in part on the command, wherein the storage device is configured to expand memory. Statement 52. An embodiment of the disclosure includes the article as described in Statement 51, wherein determining to command access to data on a storage device includes determining to command access to data on a solid state drive (SSD). Statement 53. An embodiment of the disclosure includes the article as described in Statement 52, wherein the first interface includes a cache coherence interconnect protocol. Statement 54. An embodiment of the disclosure includes the article as described in Statement 53, wherein the cache coherence interconnect protocol includes a Compute Express Link (CXL) protocol. Statement 55. An embodiment of the disclosure includes the article as described in Statement 52, wherein the second interface includes a block interface. Statement 56. An embodiment of the disclosure includes the article as described in Statement 55, wherein the block interface includes a Peripheral Component Interconnect Express (PCIe) interface. Statement 57. An embodiment of the disclosure includes the article as described in Statement 52, wherein determining to command access to data on the SSD includes determining to command access to the host device memory (HDM) of the SSD. Statement 58. An embodiment of the disclosure includes the article as described in Statement 52, wherein selecting the selected interface of the first interface and the second interface based at least in part on the command includes selecting the selected interface of the first interface or the second interface based at least in part on one of parameters of an operating system, second data in a file, metadata of the file, or a type of the command, a data size associated with the command. Statement 59. An embodiment of the disclosure includes the article as described in Statement 52, a non-transitory storage medium having stored thereon other instructions that when executed by a machine cause a command to be transmitted to the SSD using the selected interface. Statement 60. An embodiment of the disclosure includes the article as described in Statement 59, wherein transmitting the command to the SSD using the selected interface includes modifying the command based at least in part on the selected interface. Statement 61. An embodiment of the disclosure includes the article as described in Statement 60, wherein modifying the command based at least in part on the selected interface includes replacing the command with a second command based at least in part on the selected interface, the second command being different from the command. Statement 62. An embodiment of the disclosure includes the article as described in Statement 60, wherein modifying the command based at least in part on the selected interface includes replacing a first parameter of the command with a second parameter of the command based at least in part on the selected interface, the second parameter being different from the first parameter. Statement 63. An embodiment of the disclosure includes the article as described in Statement 60, wherein modifying the command based at least in part on the selected interface includes changing a packaging of the command based at least in part on the selected interface. Statement 64. An embodiment of the present disclosure includes an article comprising a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the following operations: Receiving a first command from a processor at a storage device via a first interface; Processing the first command at the storage device; Receiving a second command from a processor at the storage device via a second interface; and Processing the second command at the storage device. Statement 65. An embodiment of the present disclosure includes the article as described in Statement 64, wherein: Receiving a first command from a processor at a storage device via a first interface includes receiving a first command from a processor at a solid state drive (SSD) via a first interface; Processing the second command at the storage device includes processing the second command at the SSD; Receiving a second command from a processor at the storage device via a second interface includes receiving a second command from a processor at the SSD via a second interface; and Processing the second command at the storage device includes processing the second command at the SSD. Statement 66. An embodiment of the present disclosure includes the article as described in Statement 65, wherein the first interface includes a cache coherence interconnect protocol. Statement 67. An embodiment of the present disclosure includes the article as described in Statement 66, wherein the cache coherence interconnect protocol includes a Compute Express Link (CXL) protocol. Statement 68. An embodiment of the present disclosure includes the article as described in Statement 65, wherein the second interface includes a block interface. Statement 69. An embodiment of the present disclosure includes the article as described in Statement 68, wherein the block interface includes a Peripheral Component Interconnect Express (PCIe) interface. Statement 70. An embodiment of the present disclosure includes the article as described in Statement 65, wherein receiving a first command at the SSD via the first interface includes: Authorizing access to a host device memory (HDM) in the SSD by a processor; and Managing the HDM to a buffer in the SSD. Statement 71. An embodiment of the present disclosure includes the article as described in Statement 65, wherein the first command includes one of a load command or a store command. Statement 72. An embodiment of the present disclosure includes the article as described in Statement 65, wherein receiving a second command from a processor at the SSD via the second interface includes: Flushing a buffer in the SSD; and Reload the buffer. Statement 73. An embodiment of the present disclosure includes the article as described in Statement 72, wherein receiving the second command from the processor at the SSD via the second interface further includes remapping the HDM in the SSD to the buffer. Statement 74. An embodiment of the present disclosure includes the article as described in Statement 65, wherein the second command includes a write command. Statement 75. An embodiment of the present disclosure includes the article as described in Statement 65, wherein the second command includes a read command.

[0094] Therefore, considering the wide variety of changes in the embodiments described herein, this detailed description and the accompanying materials are intended to be illustrative only and should not be regarded as limiting the scope of the present disclosure. As claimed in the present disclosure are all such modifications within the scope and spirit of the following claims and their equivalents.

[0095] 105: Machine 110: Processor 115: Memory 120: Storage device 125: Memory controller 130: Device driver 135: Connection 205: Clock 210: Network connector 215: Bus 220: User interface 225: I / O engine 305: DAX mode 310: Host management device memory 315, 335: Command 320: Register / storage space / flash memory chip 320-1, 320-2, 320-3, 320-4, 320-5, 320-6, 320-7, 320-8: Flash memory chip 325: Buffer 330: Block mode 405: Application 410: Operating system 415: Write command 420, 485: File 425: Page cache 430: Block management 435: Transmitter 440-1, 440-2: Interface 445: PCIe Module 450: LBA Space 455: Load / Store Command 460: Virtual Memory Management 465: CXL.mem Module 470: Physical Address 475: Mode Switch 480: Modifier 505: Host Interface Layer 510: SSD Controller 515, 515-1, 515-2, 515-3, 515-4: Channel 520: Flash Translation Layer 525: Firmware 605, 610, 615, 620, 625, 630, 635, 705, 710, 715, 720, 805, 810, 815, 820, 825, 830, 835, 840, 845, 905, 910, 915, 1005, 1010, 1015, 1020, 1030: Block 1025: Dashed Line

Claims

1. A system supporting multiple access modes, the system comprising: processor; Memory, coupled to the processor; A storage device coupled to the processor, the storage device including a first interface and a second interface, the storage device being configured to expand the memory; And a mode switch for selecting a selected interface from the first interface and the second interface for commands issued by the processor, wherein the memory includes at least one physical address accessible through the first interface and the second interface.

2. The system of claim 1, wherein the storage device comprises: a storage for data; and a controller for managing the data in the storage, wherein the controller is configured to process the commands.

3. The system as claimed in claim 2, wherein the storage device further comprises: a host management device memory (HDM); and a buffer mapped from the HDM, wherein the processor can access the HDM, and the buffer can store a copy of a portion of the storage device.

4. The system as claimed in claim 1, wherein the storage device comprises a solid-state drive (SSD).

5. The system of claim 4, wherein the mode switch is configured to select one of the first interface and the second interface for a command issued by the processor based at least in part on one of the following: parameters of the operating system, second data in the file, metadata of the file or the type of the command, and the data size associated with the command.

6. The system as described in claim 4 further includes a transmitter that uses the selected interface to transmit the command to the SSD.

7. The system as described in claim 6 further includes a modifier that modifies the command at least in part based on the selected interface.

8. The system as claimed in claim 7, wherein the modifier is configured to replace the command with a second command, which is different from the command, at least in part based on the selected interface.

9. The system as claimed in claim 7, wherein the modifier is configured to replace the first parameter of the command with a second parameter of the command, which is different from the first parameter, based at least in part on the selected interface.

10. The system as claimed in claim 4, wherein the first interface includes a cache coherency interconnect protocol.

11. A storage device supporting multiple access modes, the storage device comprising: Storage, used for data; A controller for managing the data in the storage device; The first interface is used to receive the first command from the processor; and a second interface for receiving a second command from the processor, wherein the controller is configured to process the first command and the second command, and wherein the storage device extends memory, and wherein the memory includes at least one physical address accessible through the first interface and the second interface.

12. The storage device as claimed in claim 11, further comprising: Host Management Device Memory (HDM); and a buffer, mapped from the HDM, wherein the processor can access the HDM; The buffer can store a copy of a portion of the memory.

13. The storage device as claimed in claim 12 further includes a non-transitory storage medium, the non-transitory storage medium including instructions to refresh the buffer and reload the buffer at least in part based on the storage device receiving the second command.

14. A method supporting multiple access modes, the method comprising: Receive commands from the processor at the operating system level; The command is determined to access data on a storage device, the storage device including a first interface and a second interface; And at least in part based on the command, a selected interface of the first interface or the second interface is selected, wherein the storage device is configured to expand memory, and wherein the storage device includes at least one physical address accessible through the first interface and the second interface.

15. The method of claim 14, wherein determining that the command accesses data on the storage device includes determining that the command accesses data on a solid-state drive (SSD).

16. The method of claim 15, wherein determining that the command accesses data on the SSD includes determining that the command accesses the host management device memory (HDM) of the SSD.

17. The method of claim 15, wherein selecting the selected interface of the first interface and the second interface based at least in part on the command comprises selecting the selected interface of the first interface or the second interface based at least in part on one of the parameters of the operating system, second data in the file, metadata of the file or the type of the command, and the data size associated with the command.

18. The method as described in claim 15 further includes using the selected interface to transmit the command to the SSD.

19. The method of claim 18, wherein transmitting the command to the SSD using the selected interface includes modifying the command at least in part based on the selected interface.

20. The method of claim 19, wherein modifying the command at least in part based on the selected interface comprises replacing the command with a second command, which is different from the command, at least in part based on the selected interface.

Images