Patent Description:
Further relevant technologies are also known from <NPL>), which relates to N-dimensional storage; <CIT>, which relates to Zoned Name Space (ZNS) standard based storage device providing data compression and method thereof; <CIT>, which relates to technologies for providing multi-namespace using mapping memory; and <CIT>, which relates to namespace management in non-volatile memory devices.

It is with respect to these and other general considerations that embodiments have been described. Also, although relatively specific problems have been discussed, it should be understood that the embodiments should not be limited to solving the specific problems identified in the background.

Aspects of the present disclosure are directed to improving access efficiency for solid state drives.

In the following description, although numerous features are designated as optional, it is nevertheless acknowledged that all features comprised in the independent claims are not to be read as optional.

In one aspect, a method for accessing blocks of a solid state drive is provided. The method comprises receiving a starting position that identifies a first block of a contiguous block region within a namespace of the solid state drive to be accessed according to a single input/output operation, where the namespace comprises two dimensions of logical address space with respective indices for indexing blocks within a corresponding dimension of the logical address space. The method further comprises receiving a first dimensional identifier that identifies a size of the contiguous block region in a first dimension of the namespace, and a second dimensional identifier that identifies a size of the contiguous block region in a second dimension of the namespace. The method further comprises accessing blocks of the contiguous block region in response to the single input/output operation according to the starting position, the first dimensional identifier, and the second dimensional identifier.

In another aspect, a system for accessing blocks of a solid state drive is provided. The system comprises one or more NAND memory chips for data storage. The system further comprises a drive storage controller configured to access the one or more NAND memory chips and configure the one or more NAND memory chips with a namespace that comprises two dimensions of logical address space with respective indices for indexing blocks within a corresponding dimension of the logical address space. The drive storage controller is configured to: receive a starting position that identifies a first block of a contiguous block region within the namespace to be accessed according to a single input/output operation; receive a first dimensional identifier that identifies a size of the contiguous block region in a first dimension of the namespace, and a second dimensional identifier that identifies a size of the contiguous block region in a second dimension of the namespace; and access blocks of the contiguous block region in response to the single input/output operation according to the starting position, the first dimensional identifier, and the second dimensional identifier.

In yet another aspect, a non-transient computer-readable storage medium comprising instructions being executable by one or more processors is provided. When executed by the one or more processors, the instructions cause the one or more processors to: receive a starting position that identifies a first block of a contiguous block region within a namespace of a solid state drive to be accessed according to a single input/output operation, wherein the namespace comprises two dimensions of logical address space with respective indices for indexing blocks within a corresponding dimension of the logical address space; receive a first dimensional identifier that identifies a size of the contiguous block region in a first dimension of the namespace, and a second dimensional identifier that identifies a size of the contiguous block region in a second dimension of the namespace; and access blocks of the contiguous block region in response to the single input/output operation according to the starting position, the first dimensional identifier, and the second dimensional identifier.

Non-limiting and non-exhaustive examples are described with reference to the following Figures.

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These aspects may be combined, other aspects may be utilized, and structural changes may be made without departing from the appended claims. Embodiments may be practiced as methods, systems, or devices. Accordingly, embodiments may take the form of a hardware implementation, an entirely software implementation, or an implementation combining software and hardware aspects. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

The present disclosure describes various examples of systems and method for accessing data blocks using multi-dimensional addressing. Instead of a one-dimensional address space where a single value indicates a number of blocks to be accessed by an I/O operation, a solid state drive is configured for block access using multiple dimensions, such as first and second dimensions. This allows for access to a contiguous block region within the solid state drive, even when that contiguous block region is not sequential in a single dimension. Generally, a starting position is received, where the starting position identifies a first block of the contiguous block region to be accessed according to a single input/output operation. A first dimensional identifier is received that identifies a size of the contiguous block region in a first dimension, and a second dimensional identifier is received that identifies a size of the contiguous block region in a second dimension. Blocks of the contiguous block region are accessed in response to the single input/output operation according to the starting position, the first dimensional identifier, and the second dimensional identifier.

This and many further embodiments for a computing device are described herein. For instance, <FIG> shows a block diagram of an example of a system configuration for a solid state drive, according to an example embodiment. The system <NUM> includes a computing device <NUM> that is configured to access blocks of a solid state drive. The system <NUM> may also include a storage device <NUM> that is communicatively coupled with the computing device <NUM> via a network <NUM>, in some examples.

The computing device <NUM> may be any type of computing device, including a smartphone, mobile computer or mobile computing device (e.g., a Microsoft® Surface® device, a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, etc.), or a stationary computing device such as a desktop computer or PC (personal computer). The computing device <NUM> may be configured to communicate with a the storage device <NUM>, for example, using the network <NUM> (e.g., the Intemet, a local area network, etc.). The computing device <NUM> may be configured to execute one or more software applications (or "applications") and/or services and/or manage hardware resources (e.g., processors, memory, etc.), which may be utilized by users of the computing device <NUM> or processes running on the computing device <NUM>.

Computing device <NUM> comprises a processor <NUM>, a memory <NUM>, and a solid state drive (SSD) <NUM>. The processor <NUM> may be any suitable microprocessor (e.g., x86-<NUM> based processor, ARM based processor) along with suitable memory <NUM> (e.g., double data rate random access memory, embedded memory). In some examples, the processor <NUM> is implemented as a system on a chip (SoC), with or without the memory <NUM>. Although not shown, in some examples the processor <NUM> comprises or communicates with a secondary storage controller or host controller configured to communicate with storage devices, such as the SSD <NUM>. Accordingly, the processor <NUM> supports one or more logical device interfaces, such as advanced host controller interface (AHCI), non-volatile memory express (NVMe) interface (or non-volatile memory host controller interface specification), or other suitable logical device interface.

The SSD <NUM> (or semiconductor storage device) is a solid-state storage device that uses integrated circuit assemblies to store data. Generally, the SSD <NUM> may be used as a secondary storage device for the computing device <NUM> and may be implemented as a flash memory module, USB memory card, M. <NUM> SSD or other suitable module having one or more NAND flash chips or NOR flash chips. Further details of the SSD <NUM> are described below with respect to <FIG>. The processor <NUM>, memory <NUM>, and the SSD <NUM> are generally communicatively coupled by an interconnect bus <NUM>, such as a Peripheral Component Interconnect Express (PCIe) bus or M-PHY bus. In other examples, the interconnect bus <NUM> is a serial bus, parallel bus, or other suitable communication bus for sending and receiving data with the SSD <NUM>.

Storage device <NUM> may include one or more solid state drives <NUM> or other suitable storage mechanisms (not shown). The solid state drive <NUM> may generally correspond to the SSD <NUM>, in some examples. The storage device <NUM> may be a network attached storage device, cloud storage device, or other remotely accessible storage device containing one or more solid state drives, in various examples.

<FIG> shows a block diagram of an example of a solid state drive (SSD) <NUM>, according to an example embodiment. Generally, the SSD <NUM> corresponds to the SSD <NUM> and may be implemented as a hard drive, memory card, universal serial bus (USB) flash drive, embedded storage drive, or other suitable storage device. The SSD <NUM> comprises one or more memory chips <NUM> and a drive storage controller <NUM>. In the example shown in <FIG>, the SSD <NUM> comprises four NAND flash chips <NUM>, <NUM>, <NUM>, and <NUM>. In other examples, the SSD <NUM> comprises one, two, three, or more NAND flash chips. Moreover, in some examples, the SSD <NUM> uses NOR flash chips instead of, or in addition to, the NAND flash chips. The NAND flash chips <NUM>, <NUM>, <NUM>, and <NUM> generally comprise cells for storing data. Each cell may store one, two, three, or more bits and the cells may be arranged in blocks.

The drive storage controller <NUM> is configured to access and configure the NAND memory chips <NUM>, <NUM>, <NUM>, and <NUM> with one or more namespaces, as described herein. In some examples, the features of the drive storage controller <NUM> are implemented within a flash translation layer <NUM> of the drive storage controller <NUM>. The flash translation layer (FTL) generally performs logical-to-physical address translation, along with other maintenance tasks such as garbage collection, wear-leveling, bad block management, etc..

The drive storage controller <NUM> may be a non-volatile memory express (NVMe) controller, universal flash storage (UFS) controller, or other suitable controller for memory chips. Generally, the drive storage controller <NUM> supports commands that provide access to user data stored on the memory chips using an input/output (I/O) command set. In some examples, the drive storage controller <NUM> is implemented as one or more primary controllers and one or more secondary controllers that are each dependent upon a primary controller. The drive storage controller <NUM> may also comprise a cache for operational use. The cache may be implemented as a random access memory module within the drive storage controller <NUM>, as allocated or reserved blocks in the memory chips <NUM>, or a combination thereof, in various examples.

Generally, the drive storage controller <NUM> is configured to support a multi-dimensional logical address space, for example, a two-dimensional logical address space as described below with respect to <FIG>, a three-dimensional logical address space, a four-dimensional logical address space, etc. Each dimension has a corresponding index for indexing blocks within that dimension of the logical address space. A two-dimensional logical address space may be modeled as rows and columns where a first index identifies a location of a block in the first dimension (i.e., a row) and a second index identifies a location of a block in the second dimension (i.e., a column), for example. A three-dimensional logical address space may be modeled as rows, columns, and tubes, for example. The drive storage controller <NUM> generally creates a namespace as a formatted quantity of non-volatile memory that may be directly accessed by a host and comprises one or more logical blocks. A logical block is a smallest unit of data that may be read from or written by the drive storage controller <NUM>. Logical block sizes may be <NUM> bytes, <NUM> KiB, <NUM> KiB, <NUM> KiB, <NUM> KiB, or another suitable size, in various examples. Using rows and columns as an example, the individual blocks may be modeled as cells in a table or spreadsheet. In the example shown in <FIG>, the NAND flash chip <NUM> comprises four blocks in a single column, labeled as logical blocks A1, A2, A3, and A4, the NAND flash chip <NUM> comprises four blocks in a single column, labeled as B1, B2, B3, and B4, and so on. Accordingly, the SSD <NUM> comprises sixteen blocks which may be modeled as a <NUM> x <NUM> table. In contrast to a one-dimensional address space where sixteen blocks may be accessed using a single address (e.g., hexadecimal x00, x01, x02,. x0E, x0F), the drive storage controller <NUM> is configured to use a two-dimensional logical address space and as such, a first dimensional identifier, such as letters A through D, may be used to indicate a column, and a second dimensional identifier, such as number <NUM> through <NUM>, may be used to indicate a row.

Although the memory chips <NUM> are shown with only a single column of blocks, the memory chips may have any suitable arrangement of blocks with one or more rows, one or more columns, etc., in other examples. In some examples, the NAND chips may have three dimensions using multiple layers vertically (i.e., 3D NAND chips).

In some examples, the drive storage controller <NUM> supports multiple input/output (I/O) command sets, for example, an enhanced command set with two-dimensional commands and a legacy command set with one-dimensional commands. In one such example, a first primary controller (not shown) is configured to use two-dimensional commands (i.e., rows and columns) to access the memory chips <NUM>, while a second primary controller (not shown) is configured to use one-dimensional commands (i.e., hexadecimal) to access the memory chips <NUM>. In another example, a single primary controller is configured to use both one-dimensional and two-dimensional command sets.

<FIG> shows a diagram of an example namespace <NUM> of a solid state drive for two-dimensional access, according to an example embodiment. The namespace <NUM> may be mapped to all or some of the blocks within the SSD <NUM>, for example, by the drive storage controller <NUM>. As will be appreciated by those skilled in the art, the SSD <NUM> may be configured with one, two, three, or more namespaces in various examples or scenarios. Moreover, the SSD <NUM> may be configured with only two-dimensional (or multi-dimensional) namespaces, or both one-dimensional and multi-dimensional namespaces, in various examples or scenarios.

In the example shown in <FIG> and described herein, the drive storage controller <NUM> is implemented as an NVMe-compatible drive storage controller and configures the namespace <NUM>. In other words, the drive storage controller <NUM> uses and/or supports commands that are similar or based upon commands in the NVM Express Base Specification (see nvmexpress. Example commands or data structures that may be modified to support multi-dimensional logical address spaces comprise the starting logical block address (SLBA), number of logical blocks (NLB), or namespace size (NSZE) field. Other commands may be used in different implementations of the drive storage controller <NUM> (e.g., in the case of AHCI).

For the namespace <NUM>, a first logical block address (LBA) for a block <NUM> may be LBA(<NUM>, <NUM>), corresponding to a tuple representing row <NUM> and column <NUM>. Similarly, a last LBA for a block <NUM> may be LBA(Max_Row, Max_Col) where Max_Row indicates a maximum size (i.e., number of rows) of the namespace <NUM> in the first dimension and Max_Col indicates a maximum size (i.e., number of columns) of the namespace <NUM> in the second dimension. Accordingly, a block <NUM> may have LBA(<NUM>, Max_Col) and a block <NUM> may have LBA(Max_Row, <NUM>). As shown in <FIG>, Max_Col is <NUM> (i.e., <NUM> total columns) and Max_Row is <NUM> (i.e., <NUM> total rows).

With namespace <NUM> as described herein, a read operation, write operation, format operation, or other suitable operation may refer to a contiguous block region. For example, instead of a starting LBA in hexadecimal, a starting address for a contiguous block region may have a starting row LBA (SRLBA) and a starting column LBA (SCLBA). In the example shown in <FIG>, the contiguous block region <NUM> has a starting address of (<NUM>,<NUM>). Moreover, instead of a number of logical blocks (NLB), the operation may refer to a tuple representing a number of logical rows (NLR) and a number of logical columns (NLC). For example, the contiguous block region <NUM> has an NLR of <NUM> and an NLC of <NUM>. In this way, a read operation may correspond to a command of READ((<NUM>, <NUM>), (<NUM>, <NUM>)) where (<NUM>,<NUM>) denotes the starting address, (<NUM>, <NUM>) denotes a number of rows and columns to be read from the starting address.

In some examples, various operations may further include an access order, indicating whether operations within the contiguous block region should be performed in a row-first manner or column-first manner. Using the block names shown in <FIG>, a row-first manner would be A1, B1, C1, D1, A2, etc. while a column-first manner would be A1, A2, A3, A4, B1, etc..

With namespace <NUM> as described herein, a namespace size (NSZE) field may indicate the total size of the namespace <NUM> as a total size in rows and columns (Max_Row, Max_Col) instead of in a number of logical blocks (LBA <NUM> through n-<NUM>, for example).

In some examples, the drive storage controller <NUM> receives a plurality of I/O operations from an application, operating system, driver, etc. that provides a one-dimensional address for several operations of a same type (e.g., read operations, write operations). In one example, the drive storage controller <NUM> converts multiple I/O operations of the same type into a single I/O operation using the two-dimensional logical block address commands. Using the example of <FIG>, read operations such as READ(B1), READ(B2), READ(B3) may be converted into a single read operation as READ(B1, (<NUM>, <NUM>)) for a read operation starting at block B1 and continuing for <NUM> column and <NUM> rows. Other conversions of operations will be apparent to those skilled in the art. In some examples, an SSD driver (e.g., SSD driver <NUM>) of an operating system or application module converts multiple I/O operations of the same type into a single I/O operation using the two-dimensional logical block address commands. The SSD driver <NUM> may then provide the converted commands to the drive storage controller <NUM>. In other examples, the SSD driver provides an interface that comprises two-dimensional logical block address commands to other application modules.

Using the two-dimensional logical address space of the namespace <NUM>, multiple write commands may be written across different rows, but with related records aligned in a same column. This approach allows for a single read operation, vertically across a single column, to access the related records, which saves the operational costs of multiple random accesses and improves performance of the SSD <NUM>.

<FIG> shows a diagram of an example logical to physical mapping for two-dimensional access of an SSD <NUM>, according to an example embodiment. The SSD <NUM> generally correspond to the SSD <NUM>, but with updated block identifiers showing a mapping of the logical blocks shown in <FIG> onto physical blocks of the memory chips <NUM>, <NUM>, <NUM>, and <NUM>. For example, a horizontal READ((<NUM>,<NUM>), (<NUM>, <NUM>)) operation using the logical address space in <FIG> would read a single row as A1, B1, C1, and D1. This operation corresponds to a horizontal read from physical blocks A1, B1, C1, and D1, from memory chips <NUM>, <NUM>, <NUM>, and <NUM>, respectively. However, a horizontal READ((<NUM>,<NUM>), (<NUM>, <NUM>)) operation using the logical address space in <FIG> would read a single row as A2, B2, C2, and D2. This operation corresponds to a horizontal read from physical blocks D2, A2, B2, C2, from memory chips <NUM>, <NUM>, <NUM>, and <NUM>, respectively. Although the physical blocks are read out of sequential order, they may be read simultaneously because they are located on different chips. Generally, the mapping from the logical address space to physical address space of <FIG> corresponds to an offset of a column index by an amount of the row index. Specifically, the offset of the column index is <NUM> for the first row, <NUM> for the second row (shifting the physical location one chip to the right), <NUM> for the second row (shifting the physical location two chips to the right), etc. Other variations in offset will be apparent to those skilled in the art, such as an offset of the row index by an amount of the column index, offsets in a different direction, etc. In some examples, the offset is dynamically determined when configuring a namespace.

The mapping shown in <FIG> indicates that a vertical READ((<NUM>,<NUM>), (<NUM>,<NUM>)) operation using the logical address space in <FIG> would read a single column as A1, A2, A3, and A4. This operation corresponds to a vertical read from physical blocks A1, A2, A3, and A4 from memory chips <NUM>, <NUM>, <NUM>, and <NUM>, respectively. Advantageously, the physical blocks may be read simultaneously because they are located on different chips, instead of each block being located on the first memory chip <NUM>.

<FIG> shows a flowchart of an example method of accessing blocks of a solid state drive, according to an example embodiment. Technical processes shown in these figures will be performed automatically unless otherwise indicated. In any given embodiment, some steps of a process may be repeated, perhaps with different parameters or data to operate on. Steps in an embodiment may also be performed in a different order than the top-to-bottom order that is laid out in <FIG>. Steps may be performed serially, in a partially overlapping manner, or fully in parallel. Thus, the order in which steps of method <NUM> are performed may vary from one performance to the process of another performance of the process. Steps may also be omitted, combined, renamed, regrouped, be performed on one or more machines, or otherwise depart from the illustrated flow, provided that the process performed is operable and conforms to at least one claim. The steps of <FIG> may be performed by the computing device <NUM> (e.g., via the drive storage controller <NUM>), an SSD controller <NUM> (<FIG>), or other suitable computing device.

Method <NUM> begins with step <NUM>. At step <NUM>, a starting position is received that identifies a first block of a contiguous block region within a namespace of the solid state drive to be accessed according to a single input/output operation. The namespace comprises two dimensions. The starting position may be a tuple such as (<NUM>, <NUM>) for the block <NUM> for the namespace <NUM> shown in <FIG>, received by the drive storage controller <NUM>.

At step <NUM>, a first dimensional identifier that identifies a size of the contiguous block region in a first dimension of the namespace is received, and a second dimensional identifier that identifies a size of the contiguous block region in a second dimension of the namespace is received. For example, the drive storage controller <NUM> may receive a tuple for a number of logical rows (NLR) and a number of logical columns (NLC).

At step <NUM>, blocks of the contiguous block region are accessed in response to the single input/output operation according to the starting position, the first dimensional identifier, and the second dimensional identifier. For example, the drive storage controller <NUM> may perform a read operation, write operation, format operation, or other suitable operation on the contiguous block region <NUM>.

In some examples, the method <NUM> further comprises receiving an access order that prioritizes one of the first dimension or the second dimension, and accessing each of the blocks of the block region in the prioritized dimension from the first block before accessing remaining blocks of the contiguous block region. For example, the drive storage controller <NUM> may receive an access order indicating a row-first or column-first manner of accessing the blocks of the contiguous block region <NUM>.

In some examples, the starting position comprises a <NUM>-tuple having a first index that identifies a location of the first block in the first dimension and a second index that identifies the location of the first block in the second dimension. For example, the first index indicates a number of rows and the second index indicates a number of columns to find the starting position. As one example, block <NUM> has a <NUM>-tuple of (<NUM>,<NUM>) indicating its position at the sixth row and fourth column using a <NUM>-based address (i.e., (<NUM>,<NUM>) indicating a first block of the namespace).

In some examples, the starting position comprises a single value that identifies the location of the first block, the method further comprising mapping the single value to the first dimension using an integer division operation (i.e., where fractional remainders are omitted from the result) and to the second dimension using a modulo operation. For example, the block <NUM> may be identified by a single value of <NUM> (in decimal) or x53 (in hexadecimal) because an integer division of <NUM> by the row size (<NUM> based on a Max_Col of <NUM>) is <NUM> (corresponding to the sixth row) and a modulo operation of <NUM> by <NUM> (<NUM> Mod <NUM>) is <NUM> (corresponding to the fourth column).

In some examples, the single input/output operation comprises one of reading data from each block of the block region or writing data from each block of the block region.

In some examples, the method <NUM> further comprises: receiving a request for identification of the namespace; and providing a response to the request for identification that indicates a maximum size of the namespace in the first dimension and a maximum size of the namespace in the second dimension. In some examples, the response is an NSZE field that defines the maximum space of the namespace, for example, as a tuple of (<NUM>, <NUM>) for decimal or a tuple of (x0F, x0F) for hexadecimal representing <NUM> rows and <NUM> columns.

In some examples, the single input/output operation comprises formatting at least a portion of the solid state drive to configure the namespace with the size of the contiguous block region. In one such example, the size of the contiguous block region is different from a prior configuration of the namespace. For example, a namespace with a size of <NUM> rows by <NUM> columns may be resized to have <NUM> rows by <NUM> columns (maintaining a same capacity but different configuration). In other examples, the namespace may be resized to have a larger or smaller capacity, according to available space on the solid state drive.

In some examples, the namespace comprises three dimensions of logical address space where three indices are used to index blocks within the logical address space. In one such example, the method <NUM> further comprises: receiving a third dimensional identifier that identifies a size of the contiguous block region in a third dimension of the namespace. Accessing blocks of the block region comprises accessing the blocks of the contiguous block region according to the starting position, the first dimensional identifier, the second dimensional identifier, and the third dimensional identifier. In some examples, three dimensions are utilized when the memory chips <NUM> are implemented as 3D NAND chips. For three dimensions, a <NUM>-tuple may represent rows, columns, and tubes (or width, depth, layer, etc.), generally corresponding to X, Y, and Z coordinates for indexing the blocks within the logical address space.

<FIG> and the associated descriptions provide a discussion of a variety of operating environments in which aspects of the disclosure may be practiced. However, the devices and systems illustrated and discussed with respect to <FIG> are for purposes of example and illustration and are not limiting of a vast number of computing device configurations that may be utilized for practicing aspects of the disclosure, as described herein.

<FIG> is a block diagram illustrating physical components (e.g., hardware) of a computing device <NUM> with which aspects of the disclosure may be practiced. The computing device components described below may have computer and/or processor executable instructions for implementing a drive access application <NUM> on a computing device (e.g., computing device <NUM>, storage device <NUM>), including computer and/or processor executable instructions for drive access application <NUM> that can be executed to implement the methods disclosed herein. In a basic configuration, the computing device <NUM> may include at least one processing unit <NUM> and a system memory <NUM>. Depending on the configuration and type of computing device, the system memory <NUM> may comprise, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memories. The system memory <NUM> may include an operating system <NUM> and one or more program modules <NUM> suitable for running drive access application <NUM>, such as one or more components with regard to <FIG> and <FIG> and, in particular, SSD driver <NUM> (e.g., corresponding to a driver for drive storage controller <NUM>). As shown in <FIG>, the SSD driver <NUM> may be implemented as a portion of the operating system <NUM>, a portion of the application <NUM>, or a combination thereof, in various embodiments.

The operating system <NUM>, for example, may be suitable for controlling the operation of the computing device <NUM> and communication with removable storage <NUM> and/or non-removable storage <NUM>. Furthermore, embodiments of the disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. This basic configuration is illustrated in <FIG> by those components within a dashed line <NUM>. The computing device <NUM> may have additional features or functionality. For example, the computing device <NUM> may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by a removable storage device <NUM> and a non-removable storage device <NUM>. The computing device <NUM> may comprise an SSD controller <NUM>, for example, a processor or other suitable integrated circuit, configured for communications with the storage devices <NUM> and/or <NUM>. In some examples, the SSD controller <NUM> is executed by processors within the computing device <NUM>, for example, at an interface between the processing unit <NUM> (or more generally, configuration <NUM>) and the removable storage device <NUM> and/or the non-removable storage device <NUM> (e.g., at a PCIe interface). In some examples, the SSD controller <NUM> communicates with the drive storage controller <NUM> of the SSD <NUM> and/or a similar drive storage controller (not shown) of the removable storage <NUM> or non-removable storage <NUM>.

As stated above, a number of program modules and data files may be stored in the system memory <NUM>. While executing on the processing unit <NUM>, the program modules <NUM> (e.g., drive access application <NUM>) may perform processes including, but not limited to, the aspects, as described herein. Other program modules that may be used in accordance with aspects of the present disclosure, and in particular for accessing blocks of a solid state drive, may include SSD driver <NUM>.

For example, embodiments of the disclosure may be practiced via a system-on-a-chip (SOC) where each or many of the components illustrated in <FIG> may be integrated onto a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communications units, system virtualization units and various application functionality all of which are integrated (or "burned") onto the chip substrate as a single integrated circuit. When operating via an SOC, the functionality, described herein, with respect to the capability of client to switch protocols may be operated via application-specific logic integrated with other components of the computing device <NUM> on the single integrated circuit (chip). Embodiments of the disclosure may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies.

The computing device <NUM> may also have one or more input device(s) <NUM> such as a keyboard, a mouse, a pen, a sound or voice input device, a touch or swipe input device, etc. The output device(s) <NUM> such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used. The computing device <NUM> may include one or more communication connections <NUM> allowing communications with other computing devices <NUM>. Examples of suitable communication connections <NUM> include, but are not limited to, radio frequency (RF) transmitter, receiver, and/or transceiver circuitry; universal serial bus (USB), parallel, and/or serial ports.

Claim 1:
A method for accessing blocks of a solid state drive (<NUM>), the method comprising:
receiving a starting position that identifies a first block (<NUM>) of a contiguous block region (<NUM>) within a namespace (<NUM>) of the solid state drive (<NUM>) to be accessed according to a single input/output operation, wherein the namespace (<NUM>) comprises two dimensions of logical address space with respective indices for indexing blocks within a corresponding dimension of the logical address space;
receiving a first dimensional identifier that identifies a size of the contiguous block region (<NUM>) in a first dimension of the namespace (<NUM>) and a second dimensional identifier that identifies a size of the contiguous block region (<NUM>) in a second dimension of the namespace (<NUM>); and
accessing blocks of the contiguous block region (<NUM>) in response to the single input/output operation according to the starting position, the first dimensional identifier, and the second dimensional identifier; and
characterised in that the method further comprises
receiving an access order that prioritizes one of the first dimension or the second dimension; and
accessing each of the blocks of the contiguous block region (<NUM>) in the prioritized dimension from the first block (<NUM>) before accessing remaining blocks of the contiguous block region (<NUM>).