Data storage device and method using data versioning to prevent accidental updates and deletions

Abstract

The present disclosure provides data storage devices and methods for preventing accidental updates and deletions using data versioning. In one embodiment, a data storage device is provided that includes a memory and a controller. The controller is configured to receive, from a host, a command to modify data stored in the memory, wherein the data is associated with a host identifier created by the data storage device, determine whether the host is associated with the host identifier, in response to determining that the host is associated with the host identifier, modify the data, and in response to determining that the host is not associated with the host identifier, create a new version of the data without modifying the data. Other embodiments are provided.

Description

Background Technology

[0001] A host can store data in a data storage device and retrieve that data later. In many cases, data written by a host may be updated or deleted by that host or other hosts. This can happen, for example, in a shared namespace in a non-volatile fast memory (NVMe) environment. Attached Figure Description

[0002] Figure 1A This is a block diagram of a data storage device for an implementation scheme.

[0003] Figure 1B This is a block diagram illustrating a storage module in one implementation scheme.

[0004] Figure 1C This is a block diagram illustrating a hierarchical storage system implementation.

[0005] Figure 2A This illustrates an implementation scheme. Figure 1A A block diagram of the components of the controller for the data storage device shown.

[0006] Figure 2B This illustrates an implementation scheme. Figure 1A The diagram shows the components of a memory data storage device.

[0007] Figure 3 This is a block diagram of the host and data storage devices in an implementation scheme.

[0008] Figure 4 It is a block diagram of a shared namespace environment for an implementation scheme.

[0009] Figure 5A This is a diagram illustrating the logical-to-physical address mapping of an implementation without data version control.

[0010] Figure 5B This is a diagram illustrating the logical-to-physical address mapping of an implementation scheme with data version control.

[0011] Figure 6 This is a flowchart of a device management method used in an implementation of data version control to prevent accidental updates and deletions.

[0012] Figure 7 This is a flowchart of a host-assisted method for an implementation of using data version control to prevent accidental updates and deletions. Detailed Implementation

[0013] Overview

[0014] By way of description, the following embodiments relate to a data storage device and method for using data versioning to prevent accidental updates and deletions. In one embodiment, a data storage device is provided, comprising volatile memory, non-volatile memory, and a controller. The controller is configured to: receive from a host a command to modify data stored in the memory, wherein the data is associated with a host identifier created by the data storage device; determine whether the host is associated with the host identifier; modify the data in response to determining that the host is associated with the host identifier; and create a new version of the data without modifying the data in response to determining that the host is not associated with the host identifier.

[0015] In some implementations, the controller is further configured to update the logical-to-physical address table to associate the logical address with both the data and the new version of the data.

[0016] In some implementations, the entry for the logical address in the updated logical-to-physical address table is associated with a first physical memory address for the data and a second physical memory address for the new version of the data.

[0017] In some implementations, the controller is further configured to: receive a command from the host to delete data stored in the memory; determine whether the host is associated with the host identifier; delete the data without confirming the command to delete the data in response to determining that the host is associated with the host identifier; and delete the data after confirming the command to delete the data in response to determining that the host is not associated with the host identifier.

[0018] In some implementations, the controller is further configured to update the logic to the physical address table to reflect that the data has been deleted.

[0019] In some implementations, the controller is further configured to tag the data with the host identifier.

[0020] In some implementations, the controller is further configured to tag the data with a version identifier and to create new version identifiers for new versions of the data.

[0021] In some implementations, the controller is further configured to communicate with multiple hosts in a non-volatile fast memory (NVMe) environment.

[0022] In some implementations, the logical region of the memory is configured to be shared as a shared namespace among the multiple hosts.

[0023] In some implementations, the memory includes a three-dimensional memory.

[0024] In another embodiment, a method is provided to be performed in a data storage device, the data storage device including a memory for storing data. The method includes: receiving a command from a host to modify the data; determining whether the data was originally stored by the host; modifying the data in response to determining that the data was originally stored by the host; and creating a new version of the data without modifying the data in response to determining that the data was not originally stored by the host.

[0025] In some implementations, the method also includes updating the logical-to-physical address table to associate the logical address with both the data and the new version of the data.

[0026] In some implementations, the method further includes: receiving a command to delete the data from the host; determining whether the data was originally stored by the host; deleting the data without confirming the command to delete the data in response to determining that the data was originally stored by the host; and deleting the data after confirming the command to delete the data in response to determining that the data was not originally stored by the host.

[0027] In some implementations, the method also includes updating the logic to the physical address table to reflect that the data has been deleted.

[0028] In some implementations, the method also includes tagging the data with a host identifier.

[0029] In some implementations, the host identifier is used to determine whether the data was originally stored by the host.

[0030] In some implementations, the method also includes tagging the data with a version identifier and creating a new version identifier for a new version of the data.

[0031] In some implementations, the data storage device is configured to communicate with multiple hosts in a non-volatile fast memory (NVMe) environment.

[0032] In some implementations, the logical region of the memory is configured to be shared as a shared namespace among the multiple hosts.

[0033] In another embodiment, a data storage device is provided, the data storage device comprising: a memory; means for receiving from a host a command to modify data stored in the memory, wherein the data is associated with a host identifier created by the data storage device; means for determining whether the host is associated with the host identifier; means for modifying the data in response to determining that the host is associated with the host identifier; and means for creating a new version of the data without modifying the data in response to determining that the host is not associated with the host identifier.

[0034] Other implementations are feasible, and each of these implementations can be used individually or in combination. Therefore, various implementations will now be described with reference to the accompanying drawings.

[0035] Implementation Plan

[0036] The following implementation relates to a data storage device (DSD). As described herein, a "data storage device" refers to a device that stores data. Examples of DSDs include, but are not limited to, hard disk drives (HDDs), solid-state drives (SSDs), tape drives, hybrid drives, etc. Details of an example DSD are provided below.

[0037] exist Figures 1A to 1C The diagram shows data storage devices suitable for implementing various aspects of these implementation schemes. Figure 1A This is a block diagram illustrating a data storage device 100 according to one embodiment of the subject matter described herein. Reference Figure 1A The data storage device 100 includes a controller 102 and non-volatile memory, which may consist of one or more non-volatile memory dies 104. As described herein, the term die refers to a collection of non-volatile memory cells formed on a single semiconductor substrate, and the associated circuitry for managing the physical operations of those non-volatile memory cells. The controller 102 interacts with a host system and transmits sequences of commands for read, program, and erase operations to the non-volatile memory die 104.

[0038] Controller 102 (which may be a non-volatile memory controller (e.g., flash memory, resistive random access memory (ReRAM), phase-change memory (PCM), or magnetoresistive random access memory (MRAM) controller)) may take the form of, for example, processing circuitry, a microprocessor or processor, and a computer-readable medium storing computer-readable program code (e.g., firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Controller 102 may be configured with hardware and / or firmware to perform the various functions described below and shown in the flowcharts. Additionally, some components shown as internal to the controller may also be stored external to the controller, and other components may be used. Furthermore, the phrase "operationally communicating with..." may mean communicating directly or indirectly (wired or wirelessly) with one or more components, or communicating through one or more components, which may or may not be shown herein.

[0039] As used herein, a nonvolatile memory controller is a device that manages data stored on nonvolatile memory and communicates with a host device such as a computer or electronic device. In addition to the specific functions described herein, a nonvolatile memory controller can have various functions. For example, a nonvolatile memory controller can format the nonvolatile memory to ensure that the memory is operating correctly, identify bad nonvolatile memory cells, and allocate spare cells to replace future failed cells. Some portions of the spare cells can be used to house firmware to operate the nonvolatile memory controller and implement other features. In operation, when the host needs to read data from or write data to the nonvolatile memory, it can communicate with the nonvolatile memory controller. If the host provides a logical address to read / write data, the nonvolatile memory controller can translate the logical address received from the host into a physical address in the nonvolatile memory. (Alternatively, the host may provide a physical address.) The non-volatile memory controller may also perform a variety of memory management functions, such as, but not limited to, wear leveling (allocating writes to specific memory blocks to avoid wear that would otherwise be repeatedly written to) and garbage collection (moving only valid data pages to a new block after a block is full, so that the entire block can be erased and reused).

[0040] The non-volatile memory die 104 may comprise any suitable non-volatile memory medium, including resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), phase-change memory (PCM), NAND flash memory cells, and / or NOR flash memory cells. The memory cells may be in the form of solid-state (e.g., flash memory) memory cells and may be programmable once, programmable multiple times, or programmable many times. The memory cells may also be single-level cells (SLC), multi-level cells (MLC), three-level cells (TLC), or other memory cell-level technologies known now or developed thereafter. Furthermore, the memory cells may be manufactured in a two-dimensional or three-dimensional manner.

[0041] The interface located between the controller 102 and the non-volatile memory die 104 can be any suitable flash memory interface, such as switching modes 200, 400, or 800. In one embodiment, the data storage device 100 can be a card-based system, such as a Secure Digital Card (SD) or a Micro Secure Digital (Micro SD) card. In an alternative embodiment, the data storage device 100 can be part of an embedded data storage device.

[0042] Although Figure 1AIn the example shown, data storage device 100 (sometimes referred to herein as a storage module) includes a single channel between controller 102 and non-volatile memory die 104; however, the subject matter described herein is not limited to having a single memory channel. For example, in some storage system architectures (such as...) Figure 1B and Figure 1C In the architecture shown, there can be two, four, eight, or more memory channels between the controller and the memory device, depending on the controller's capabilities. In any of the embodiments described herein, even if a single channel is shown in the figures, there can be more than one single channel between the controller and the memory die.

[0043] Figure 1B A storage module 200 is shown, comprising multiple non-volatile data storage devices 100. Thus, the storage module 200 may include a storage controller 202 that interacts with a host and a data storage device 204 that includes the multiple data storage devices 100. The interface between the storage controller 202 and the data storage devices 100 may be a bus interface, such as a Serial Advanced Technology Attachment (SATA), a Peripheral Component Rapid Interconnect (PCIe) interface, or a Double Data Rate (DDR) interface. In one embodiment, the storage module 200 may be a solid-state drive (SSD) or a non-volatile dual in-line memory module (NVDIMM), such as those found in server PCs or portable computing devices such as laptops and tablets.

[0044] Figure 1C This is a block diagram illustrating a hierarchical storage system. The hierarchical storage system 250 includes a plurality of storage controllers 202, each of which controls a corresponding data storage device 204. A host system 252 can access the memory within the storage system 250 via a bus interface. In one embodiment, the bus interface may be a Non-Volatile Memory Fast (NVMe) or Fibre Channel Ethernet (FCoE) interface. In one embodiment, Figure 1C The system shown can be a rack-mountable mass storage system that can be accessed by multiple host computers, such as in a data center or other locations where mass storage is required.

[0045] Figure 2AThis is a block diagram illustrating exemplary components of controller 102 in more detail. Controller 102 includes a front-end module 108 that interacts with a host, a back-end module 110 that interacts with one or more non-volatile memory dies 104, and various other modules that perform functions now described in detail. Modules may take the form of, for example, packaged functional hardware units designed for use in conjunction with other components, portions of program code (e.g., software or firmware) executable by a (micro)processor or processing circuitry that typically performs a specific function among related functions, or stand-alone hardware or software components that interact with a larger system. Furthermore, the “means” for performing functions may be implemented using at least any of the structures described herein for a controller, and may be pure hardware or a combination of hardware and computer-readable program code.

[0046] Referring again to the module of controller 102, the buffer management / bus controller 114 manages the buffers in random access memory (RAM) 116 and controls the internal bus arbitration of controller 102. Read-only memory (ROM) 118 stores the system boot code. Although Figure 2A The RAM 116 and ROM 118 are shown positioned separately from the controller 102, but in other embodiments, one or both of them may be located within the controller. In yet another embodiment, portions of the RAM and ROM may be located both inside and outside the controller 102.

[0047] Front-end module 108 includes a host interface 120 and a physical layer interface (PHY) 122 that provide an electrical interface to the host or next-level storage controller. The type of host interface 120 can be selected depending on the type of memory used. Examples of host interfaces 120 include, but are not limited to, SATA, SATA Express, Serial Attached Small Computer System Interface (SAS), Fibre Channel, Universal Serial Bus (USB), PCIe, and NVMe. Host interface 120 is typically used for transmitting data, control signals, and timing signals.

[0048] Backend module 110 includes an error correction code (ECC) engine 124 that encodes data bytes received from the host and decodes and error-corrects data bytes read from non-volatile memory. Command sequencer 126 generates command sequences, such as programming and erasing command sequences, to be transmitted to non-volatile memory die 104. RAID (Redundant Array of Independent Drives) module 128 manages the generation of RAID parity and the recovery of failed data. RAID parity can be used as an additional level of integrity protection for data written to the memory device. In some cases, RAID module 128 may be part of ECC engine 124. Memory interface 130 provides command sequences to and receives status information from non-volatile memory die 104. In one embodiment, memory interface 130 may be a double data rate (DDR) interface, such as a switching mode 200, 400, or 800 interface. Flash control layer 132 controls the overall operation of backend module 110.

[0049] The data storage device 100 also includes other discrete components 140, such as external electrical interfaces, external RAM, resistors, capacitors, or other components that can interact with the controller 102. In an alternative embodiment, one or more of the physical layer interface 122, RAID module 128, media management layer 138, and buffer management / bus controller 114 are optional components that are not required in the controller 102.

[0050] Figure 2B This is a block diagram showing the components of the non-volatile memory die 104 in more detail. The non-volatile memory die 104 includes peripheral circuitry 141 and a non-volatile memory array 142. The non-volatile memory array 142 includes non-volatile memory cells for storing data. The non-volatile memory cells can be any suitable non-volatile memory cells, including ReRAM, MRAM, PCM, NAND flash memory cells, and / or NOR flash memory cells in a two-dimensional and / or three-dimensional configuration. The non-volatile memory die 104 also includes a data cache 156 for caching data. The peripheral circuitry 141 includes a state machine 152 that provides status information to the controller 102.

[0051] Return again Figure 2AThe flash control layer 132 (which will be referred to herein as the Flash Translation Layer (FTL), or more generally as the “media management layer,” since the memory may not be flash) handles flash errors and interacts with the host. Specifically, the FTL (which may be an algorithm in the firmware) is responsible for the internals of memory management and translates writes from the host into writes to memory. An FTL may be necessary because memory may have limited endurance, may only have a few pages written to, and / or may not be written to at all (unless it is erased as a block). The FTL understands these potential limitations of the memory, which may not be visible to the host. Therefore, the FTL attempts to translate writes from the host into writes to memory.

[0052] The FTL may include a logical-to-physical address (L2P) mapping and an allocated cache memory. In this way, the FTL translates logical block addresses (“LBAs”) from the host into physical addresses in memory. The FTL may include other features such as, but not limited to, power-down recovery (which allows the FTL’s data structures to recover in the event of a sudden power loss) and wear leveling (which makes wear even across memory blocks to prevent some blocks from becoming excessively worn, which would lead to a greater chance of failure).

[0053] Returning to the attached diagram, Figure 3 This is a block diagram of a host 300 and a data storage device 100 according to one embodiment. The host 300 may take any suitable form, including but not limited to a computer, mobile phone, tablet computer, wearable device, digital video recorder, surveillance system, etc. In this embodiment, the host 300 (here, the computing device) includes a processor 330 and a memory 340. In one embodiment, computer-readable program code stored in the host memory 340 configures the host processor 330 to perform the actions described herein. Therefore, the actions performed by the host 300 are sometimes referred to herein as being performed by an application (computer-readable program code) running on the host 300.

[0054] As described above, host 300 can store data in data storage device 100 and retrieve that data later. In many cases, data written by host 300 may be updated or deleted by host 300 or other hosts. This can occur, for example, in an NVMe shared namespace environment, where multiple hosts can access the shared namespace and can create their own versions of the same logical region, and are also allowed to access other versions. Such environments... Figure 4 As shown in the figure. However, it should be noted that these embodiments can be used in other environments, and shared namespace environments should not be interpreted into the claims unless expressly stated in the claims.

[0055] like Figure 4As shown, the data storage device 400 includes two NVMe controllers, each connected to a different PCIe port to connect to the host 300. The first NVMe controller is associated with namespace identifiers (NSIDs) 1 and 2, and the second NVMe controller is associated with namespace identifiers (NSIDs) 2 and 3. NSID 1 has a memory region designated as namespace (NS) A, NSID 2 has a memory region designated as namespace NS B, and NSID 3 has a memory region designated as namespace NS C. Since NS B is shared by both hosts, each host can write data to the namespace and modify or delete that data.

[0056] There may be situations where users want to revert to an older version of the updated data. For example, if the data is a document that was updated using changes, a user might want to view the original version of the document before the changes were made. The following implementation can be used to allow hosts to access previous versions of the data, which may have been updated by that host or another host. More specifically, if multiple hosts modify the same logical zone, and all versions are accessible to all other hosts, the data storage device can maintain version control over the data in the shared namespace.

[0057] More generally, using these implementations, data storage device 100 can prevent accidental updates / deletions of data by enabling device-side versioning. This can be handled either by obtaining input from host 300 regarding whether versioning of written data is permitted or by determining whether data versioning is enabled on the data storage device 100 itself based on device usage. The controller 102 in data storage device 100 can create additional layers in a logical-to-physical address table in the form of a list to accommodate different physical locations for different versions of data, thereby dynamically adding extra space only for those areas that have been changed when versioning is enabled.

[0058] In one implementation, data requiring version control is tagged so that data storage device 100 is aware that special processing of the data is needed (e.g., for data version control and / or accidental deletion protection). Tagging can be performed by data storage device 100 or by host 300. These two alternatives are discussed below. It should be noted that these alternatives can be used individually or in combination. It should also be noted that in one implementation, all hosts have access to all versions of the data. Hosts can be aware of ongoing version control and therefore can be aware that some additional space is being occupied by other copies (versions).

[0059] First, let's turn to an implementation where the data storage device 100 marks the data with a "host ID" and / or a "version ID" for version control. When the same host updates the data, this is typically an overwrite. However, when another host attempts to update data written by another host, it is prompted whether to create a new version while retaining the older version written by the other host. If another host attempts to delete the data, it will be prompted that the other host wrote the data and whether it still wants to delete it. Now, let's combine... Figure 6 The flowchart 600 in the document describes the implementation scheme in more detail.

[0060] like Figure 6 As shown, in this embodiment, when data storage device 100 receives data from host 300 to store in memory, controller 102 marks the data (605) with the host's identifier (host ID) and the data's version identifier (version ID). When data storage device 100 receives a command to modify data, controller 102 determines whether the command is to delete data (610) or modify data (630). (In addition to or instead of data version control, accidental deletion prevention can also be used, as both can be triggered by data marked as "important".)

[0061] If the command is to delete data, controller 102 determines whether the command originates from the same host as the host that initially wrote the data (615). If it is the same host, data storage device 100 assumes that the host knows what it is doing, and controller 102 deletes the data without first requesting confirmation (620). If a different host is requesting data deletion, controller 102 requests confirmation from that host before deleting the data (625). This serves as a double check and ensures that the host genuinely wants to proceed with the deletion. After the data is deleted, controller 102 updates the logic to the physical address table.

[0062] If the command is to modify data, controller 102 determines whether the command originates from the same host as the host that initially wrote the data (635). If it is the same host, data storage device 100 assumes that the host knows what it is doing, and controller 102 overwrites the old data with the new data (640). If a different host is requesting to modify data, controller 102 determines whether that host is attempting to create a new version of the data (645). If not, the data is overwritten (640). However, if the host is attempting to create a new version of the data, controller 102 creates the new version of the data and stores it in memory (650). Controller 102 also updates the logical-to-physical address table to accommodate the new version (650).

[0063] As described above, in another implementation, the host (user) marks data as "important" to prevent accidental updates / deletion. In this implementation, when the same host makes any changes to the data, it is given the option to update (overwrite) the file or create a new version of the file. When a different host attempts to make any changes to the data, it will be prompted whether to retain the older version. Thus, regardless of the host, a prompt will be given requiring confirmation for deletion because the host previously marked the data as important. This will be combined with... Figure 7 The flowchart 700 in the document describes the implementation scheme in more detail.

[0064] like Figure 7 As shown, in this embodiment, identifying data subject to anti-tampering technology is the responsibility of the host, not the data storage device 100. Therefore, as Figure 7 As shown, the host first marks the data it considers important, and then sends the data to the data storage device 100 for storage in the memory (705). When the data storage device 100 receives a command to change the data, the controller 102 determines whether the command is to delete the data (710) or to modify the data (720).

[0065] If the command is to delete data, controller 102 requests confirmation from the host before deleting the data (715). Since the data is designated as important, this acts as a double check and ensures that the host actually wants to proceed with the deletion. Once confirmation is received, controller 102 deletes the data and updates the logic to the physical address table (720).

[0066] If the command modifies data, controller 102 determines whether the host is attempting to create a new version of the data (730). If not, the data is overwritten (735). However, if the host is attempting to create a new version of the data, controller 102 creates the new version of the data and stores it in memory (740). Controller 102 also updates the logical-to-physical address table to accommodate the new version. Therefore, in the case of logical-to-physical address translation page updates / deletions in the Flash Translation Layer (FTL) module's managed list, backend support from data storage device 100 may be required.

[0067] To handle backend support for data versioning in any of the above implementations, the logical-to-physical address mapping table can be modified to include information about data versions. Consider an example where a host writes logical block addresses (LBAs) 0-1000 and then rewrites LBAs 500-700 (“Version 1”). Instead of invalidating the older LBAs 500-700 as “Version 0” (another switchable address translation (SAT) layer used to maintain LBA versions), controller 102 maintains the older LBAs 500-700 as “Version 0”, rather than invalidating them as would be normally. Any host can access any version of data (e.g., a document) because controller 102 is aware of the different versions of the data document. Hosts are also allowed to delete specific versions of documents, which may also require additional confirmation to prevent accidental deletion.

[0068] Figure 5A and Figure 5B The diagram illustrates a logical-to-physical address mapping, showing a backend logical-to-physical (L2P) address mapping that supports data versioning. Figure 5A A typical L2P mapping is shown, where each LBA range is associated with a physical address in memory. Figure 5B This demonstrates how to maintain L2P mappings in the backend to accommodate data versioning. For example... Figure 5B As shown, this table introduces another layer of L2P mapping, which creates entries only for specific logical regions undergoing version control. The table utilizes a linked list containing different physical regions where different versions of data exist. This list allows for the dynamic addition and deletion of version entries and their physical locations.

[0069] Different versions of the same logical region can be identified using a host ID and / or a version ID. An additional layer of L2P mapping can be used only for the changed logical region (versioned data), in which case the unversioned portion of the logical region remains unchanged, as in a typical system. Any host can access data from data storage device 100 based on the host ID and / or version ID. Multiple combinations of data access can be provided. In some cases, the host can also provide specific keys for certain logical data, which can protect certain versions from certain hosts. An additional advantage exists if data storage device 100 allows hosts to compare versions and provide differences by only analyzing the LBA versions within the LBA range already stored in the control block, avoiding an actual comparison of the entire data.

[0070] There are many advantages associated with these implementations. For example, these implementations can be used to prevent accidental updates to data by creating new versions, to prevent accidental deletion by requiring deletion confirmation when data is marked as important, and to version control data to allow any host to access different versions of data in a shared namespace. Furthermore, with these implementations, only the differences between the two versions of data can be added to the storage device as part of an update (this difference can be in terms of the logical area stored as control data). Moreover, with these implementations, the data storage device 100 can have minimal overhead for maintaining versions of data to facilitate this feature. Additionally, hosts can provide differences in versions where different LBA areas can be returned by a simple lookup on the SAT without actual data comparison.

[0071] As mentioned above, these implementations can be highly beneficial for NVMe shared namespace environments where multiple hosts can access and modify / delete data in a shared logical memory area. With these implementations, version control and confirmation prompts can be used to prevent accidental updates or deletions of data. Furthermore, these implementations can be used in environments where data storage devices (e.g., retail devices) are in the presence of human users, or in other environments such as automotive, IoT, or industrial environments. For example, host IDs / file IDs can be used in conjunction with version control enabling / disabling in automotive / enterprise use cases to understand requirements in the environment without manual intervention. Similarly, if version control is enabled, version IDs can be associated with a specific host (host ID), thus eliminating the need for manual intervention.

[0072] Finally, as mentioned above, any suitable type of memory can be used. Semiconductor memory devices include volatile memory devices, such as dynamic random access memory (“DRAM”) or static random access memory (“SRAM”) devices, non-volatile memory devices, such as resistive random access memory (“ReRAM”), electrically erasable programmable read-only memory (“EEPROM”), flash memory (which can also be considered a subset of EEPROM), ferroelectric random access memory (“FRAM”), and magnetoresistive random access memory (“MRAM”), as well as other semiconductor elements capable of storing information. Each type of memory device can have different configurations. For example, flash memory devices can be configured in a NAND configuration or a NOR configuration.

[0073] The memory device can be formed from passive and / or active components in any combination. As a non-limiting example, a passive semiconductor memory element includes a ReRAM device element, which in some embodiments includes resistivity-switching storage elements such as antifuse, phase-change materials, etc., and optionally includes guiding elements such as diodes. As a further non-limiting example, an active semiconductor memory element includes EEPROM and flash memory device elements, which in some embodiments include elements having charge storage regions, such as floating gates, conductive nanoparticles, or charge storage dielectric materials.

[0074] Multiple memory elements can be configured such that they are connected in series or that each element can be accessed individually. By way of non-limiting example, a flash memory device (NAND memory) in a NAND configuration typically contains memory elements connected in series. A NAND memory array can be configured such that the array consists of multiple strings of memory, where a string consists of multiple memory elements sharing a single bit line and being accessed as a group. Alternatively, memory elements can be configured such that each element can be accessed individually, for example, in a NOR memory array. NAND memory configurations and NOR memory configurations are examples, and memory elements can be configured in other ways.

[0075] Semiconductor memory elements located within and / or above a substrate can be arranged in two or three dimensions, such as two-dimensional or three-dimensional memory structures.

[0076] In a two-dimensional memory structure, semiconductor memory elements are arranged in a single plane or a single memory device level. Typically, in a two-dimensional memory structure, the memory elements are arranged in a plane (e.g., in the xz plane) that extends substantially parallel to the main surface of the substrate supporting the memory elements. The substrate may be a wafer on which layers of the memory elements are formed, or it may be a carrier substrate attached to the memory elements after they have been formed. As a non-limiting example, the substrate may include a semiconductor, such as silicon.

[0077] Memory elements can be arranged in a single memory device level in an ordered array, such as in multiple rows and / or columns. However, memory elements can be arranged in unconventional or non-orthogonal configurations. Each memory element may have two or more electrodes or contact lines, such as bit lines and word lines.

[0078] The three-dimensional memory array is arranged such that the memory elements occupy multiple planes or multiple memory device levels, thereby forming a three-dimensional structure (i.e., in the x, y and z directions, where the y direction is substantially perpendicular to the main surface of the substrate, and the x and z directions are substantially parallel to the main surface of the substrate).

[0079] As a non-limiting example, a three-dimensional memory structure can be vertically arranged as a stack of multiple two-dimensional memory device levels. As another non-limiting example, a three-dimensional memory array can be arranged as multiple vertical columns (e.g., columns extending substantially perpendicular to the main surface of the substrate, i.e., in the y-direction), wherein each column has multiple memory elements. The columns can be arranged in a two-dimensional configuration, for example, in the xz plane, resulting in a three-dimensional arrangement of the memory elements, where the elements are on multiple vertically stacked memory planes. Other configurations of the three-dimensional memory elements can also constitute a three-dimensional memory array.

[0080] As a non-limiting example, in a three-dimensional NAND memory array, memory elements may be coupled together to form NAND strings within a single horizontal (e.g., xz) memory device level. Alternatively, memory elements may be coupled together to form vertical NAND strings spanning multiple horizontal memory device levels. Other three-dimensional configurations are conceivable, where some NAND strings contain memory elements within a single memory level, while others contain memory elements spanning multiple memory levels. Three-dimensional memory arrays can also be designed in NOR and ReRAM configurations.

[0081] Typically, in a monolithic three-dimensional memory array, one or more memory device classes are formed over a single substrate. Optionally, the monolithic three-dimensional memory array may also have one or more memory layers that are at least partially within a single substrate. As a non-limiting example, the substrate may include a semiconductor, such as silicon. In a monolithic three-dimensional array, the layer constituting each memory device class of the array is typically formed on the layer of the underlying memory device class of the array. However, the layers of adjacent memory device classes in a monolithic three-dimensional memory array may be shared or may have intervening layers between memory device classes.

[0082] Two-dimensional arrays can then be formed individually and then packaged together to form a non-monolithic memory device with multiple memory layers. For example, a non-monolithic stacked memory can be constructed by forming memory stages on separate substrates and then stacking the memory stages on top of each other. The substrates can be thinned or removed from the memory device stages before stacking, but since the memory device stages are initially formed on separate substrates, the resulting memory array is not a monolithic three-dimensional memory array. Furthermore, multiple two-dimensional or three-dimensional memory arrays (monolithic or non-monolithic) can be formed on separate chips and then packaged together to form a stacked chip memory device.

[0083] Typically, associated circuitry is required to operate and communicate with the memory element. As a non-limiting example, a memory device may have circuitry for controlling and driving the memory element to perform functions such as programming and reading. This associated circuitry may be located on the same substrate as the memory element and / or on a separate substrate. For example, a controller for memory read-write operations may be located on a separate controller chip and / or on the same substrate as the memory element.

[0084] Those skilled in the art will recognize that the present invention is not limited to the described two-dimensional and three-dimensional structures, but covers all relevant memory structures as described herein and as understood by those skilled in the art to be of the spirit and scope of the invention.

[0085] The foregoing detailed description is intended to be understood as an illustration of the selected forms in which the invention may take place, and not as a definition of the invention. The scope of the claimed invention is intended to be defined only by the following claims (including all equivalents). Finally, it should be noted that any aspect of any embodiment described herein may be used alone or in combination with each other.

Claims

1. A data storage device, comprising: Memory; and The controller is configured to: Receive a command from the host to modify data stored in the memory, wherein the data is associated with a host identifier created by the data storage device; Determine whether the host is associated with the host identifier; In response to determining that the host is associated with the host identifier, the data is modified; as well as In response to determining that the host is not associated with the host identifier, a new version of the data is created without modifying the data.

2. The data storage device of claim 1, wherein the controller is further configured to update the logical-to-physical address table to associate the logical address with both the data and the new version of the data.

3. The data storage device of claim 2, wherein the entry for the logical address in the updated logical-to-physical address table is associated with a first physical memory address for the data and a second physical memory address for the new version of the data.

4. The data storage device according to claim 1, wherein, The controller is further configured to: Receive a command from the host to delete the data stored in the memory; Determine whether the host is associated with the host identifier; In response to determining that the host is associated with the host identifier, the data is deleted without confirming the command to delete the data; as well as In response to determining that the host is not associated with the host identifier, the data is deleted after confirming the command to delete the data.

5. The data storage device of claim 4, wherein the controller is further configured to update the logic to the physical address table to reflect that the data has been deleted.

6. The data storage device of claim 1, wherein the controller is further configured to mark the data with the host identifier.

7. The data storage device of claim 1, wherein the controller is further configured to mark the data with a version identifier and to create a new version identifier for the new version of the data.

8. The data storage device of claim 1, wherein the controller is further configured to communicate with a plurality of hosts in a non-volatile fast memory (NVMe) environment.

9. The data storage device of claim 8, wherein the logical region of the memory is configured to be shared as a shared namespace among the plurality of hosts.

10. The data storage device according to claim 1, wherein, The memory includes a three-dimensional memory.

11. A method comprising: Perform the following operations in a data storage device, the data storage device including a memory for storing data: Receive a command from the host to modify the data; Determine whether the data was initially stored by the host; In response to determining that the data was originally stored by the host, the data is modified; as well as In response to determining that the data was not originally stored by the host, a new version of the data is created without modifying the data.

12. The method of claim 11, further comprising updating the logical-to-physical address table to associate the logical address with both the data and the new version of the data.

13. The method of claim 11, further comprising: Receive a command to delete the data from the host; Determine whether the data was initially stored by the host; In response to determining that the data was originally stored by the host, the data is deleted without confirming the command to delete the data; as well as In response to determining that the data was not originally stored by the host, the data is deleted after confirming the command to delete the data.

14. The method of claim 13, further comprising updating the logical-to-physical address table to reflect that the data has been deleted.

15. The method of claim 11, further comprising tagging the data with a host identifier.

16. The method of claim 15, wherein the host identifier is used to determine whether the data was initially stored by the host.

17. The method of claim 11, further comprising: The data is marked with a version identifier; as well as Create a new version identifier for the new version of the data.

18. The method of claim 11, wherein the data storage device is configured to communicate with a plurality of hosts in a non-volatile fast memory (NVMe) environment.

19. The method of claim 18, wherein the logical region of the memory is configured to be shared as a shared namespace among the plurality of hosts.

20. A data storage device, comprising: Memory; A means for receiving from a host a command to modify data stored in the memory, wherein the data is associated with a host identifier created by the data storage device; A means for determining whether the host is associated with the host identifier; Means for modifying the data in response to determining that the host is associated with the host identifier; and A means for creating a new version of the data without modifying the data in response to determining that the host is not associated with the host identifier.

Images