Using internal operation files with known modes on multiple devices
By using internal file operations to manage storage devices, the complexity and performance issues associated with current control methods are addressed, enabling efficient and streamlined device management through file-based control.
Patent Information
- Application Number
- CN202480005347.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-07-18
- Filing Date
- 2024-05-17
- Publication Date
- 2025-07-15
AI Technical Summary
The prior art requires expertise when performing management control operations in storage devices, which are lengthy and can lead to performance degradation.
Use the file mode generator to generate special files in the storage device, identify and execute vendor-specific commands through the file mode engine, simplifying management control operations.
Simplifies the configuration and management control operations of storage devices, improves device performance, and reduces the impact of verbose operations on performance.
Smart Images

Figure CN120322757A_ABST
Abstract
Description
[0001] Cross - Reference to Related Applications
[0002] This application claims the benefit of the entire content of U.S. Non - provisional Application No. 18 / 354,174, entitled "Using Internal Operation Files Having Known Patterns Across Multiple Devices", filed with the United States Patent and Trademark Office on July 18, 2023, and incorporated herein by reference for all purposes. Background Art Field of the Invention
[0003] Embodiments of the present disclosure generally relate to improving administrative control through file operation control.
[0004] Description of Related Technologies
[0005] To perform administrative control in a storage device, external tools are used. In the case where external developers use external tools, sometimes such use requires more expertise than normal use. Some examples of internal operations include, but are not limited to: device locking, device formatting (full format or encrypted erase), device reset statistics, changing device power consumption by changing the power mode, enabling / disabling the write cache, adding or removing internal storage processing steps for acceleration (strong / weak error correction code protection), enabling or disabling storage device features (such as host memory buffer (HMB) support), flushing the cache, and using a dashboard configured to upgrade firmware (FW) to read smart counters. If a device wants to perform these complex internal operations, some expertise is required.
[0006] When performing these operations, sometimes the user has to move between several applications and settings to complete the operation. In addition, when the user is required to move to a certain setting, there may be a situation where the mode required to complete the operation must be changed. When selecting these modes, permission to perform the operation is requested from the user. For example, for a format change, if the device is in a read - only mode where it needs to be written, and if the device is locked, the user must unlock the device. Once the device is unlocked, the user must authenticate before the change can be made.
[0007] The problem with current methods of changing administrative control is that long operations are required to change simple settings or modes. These operations increase the usage of the device, which may lead to performance degradation.
[0008] Therefore, there is a need in the art to improve administrative control operations through files with operation instructions. Summary of the Invention
[0009] Use a file to control the device instead of using an external tool to perform management control operations on the device. When management control needs to be changed, use a file mode generator to generate a special file in the device. When the special file is written to the storage device, the file mode engine recognizes it as a special file created to extract vendor-specific commands. When the special file is written to the storage device, the device will recognize the special file and execute the operations indicated in the special file. The user can use the special file for single use or future use when needed. In the case of future use, the special file can be recognized by other devices that require the special file to execute vendor-specific commands.
[0010] In one embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive from a host device a command to generate a special file for a specific operation; generate the special file; receive from a second data storage device a request to provide the special file to the second data storage device; and provide the special file to the second data storage device.
[0011] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive from a host device a command to perform an operation; detect that the operation is an operation that includes a known pattern; request from a second data storage device a special file associated with the known pattern; verify the special file; and perform the operation.
[0012] In another embodiment, a data storage device includes: means for storing data; and a controller coupled to the means for storing data, wherein the controller includes: a host interface module that includes a file mode generator; and a file mode engine configured to recognize an operation that includes a known pattern, wherein the controller is configured to: use the file mode engine to detect that a first command from a host device conforms to a first known pattern; retrieve a first special file from a second data storage device, wherein the first special file includes the first known pattern and a first operation associated with the first command; generate a second special file having a second known pattern different from the first known pattern, wherein the second special file is generated in response to a second command from the host device; and send the second special file to a third data storage device, wherein the first special file and the second special file can be used multiple times by other data storage devices. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] To understand the above features of the present disclosure in detail, the present disclosure briefly outlined above can be described more specifically by referring to the implementation examples, some of which are shown in the accompanying drawings. However, it should be noted that the accompanying drawings only show typical implementation examples of the present disclosure and should not be regarded as a limitation on the scope of the present disclosure, because the present disclosure allows other equivalent implementation examples.
[0014] Figure 1 is a schematic block diagram showing a storage system according to certain implementation examples, where a data storage device can be used as a storage device for a host device.
[0015] Figure 2 is a schematic block diagram showing a storage system with a file mode engine according to one implementation example.
[0016] Figure 3 is a block diagram showing a special file format according to certain implementation examples.
[0017] Figure 4A is a flowchart showing a method for file mode generation according to certain implementation examples.
[0018] Figure 4B is a flowchart showing a method for file mode recognition according to certain implementation examples.
[0019] Figure 5 is a block diagram showing a storage system that utilizes file modes in a storage device according to certain implementation examples.
[0020] Figure 6 is a flowchart showing a method for file mode generation and file mode recognition according to certain implementation examples.
[0021] For ease of understanding, wherever possible, the same reference numerals are used to denote the same elements common to the accompanying drawings. It is contemplated that the elements disclosed in one implementation example can be beneficially used in other implementation examples without specific recitation. Detailed Description
[0022] In the following text, reference is made to embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the features and elements below, whether or not they relate to different embodiments, is contemplated for implementing and practicing the present disclosure. Additionally, although the embodiments of the present disclosure may achieve advantages over other possible solutions and / or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the present disclosure. Thus, the aspects, features, embodiments, and advantages below are merely illustrative and are not to be considered elements or limitations of the appended claims unless expressly recited therein. Similarly, references to "the present disclosure" should not be construed as generalizations of any inventive subject matter disclosed herein and are not to be considered elements or limitations of the appended claims unless expressly recited therein.
[0023] A file is used to control the device instead of using an external tool to perform management control operations on the device. When a change in management control is needed, a file mode generator is used to generate a special file in the device. When the special file is written to the storage device, the file mode engine recognizes the special file created for extracting vendor-specific commands. When the special file is written to the storage device, the device will recognize the special file and execute the operations indicated in the special file. The user can use the special file for single use or future use when needed. In the case of future use, the special file can be recognized by other devices that need the special file to execute vendor-specific commands.
[0024] Figure 1 FIG. is a schematic block diagram of a storage system 100 having a data storage device 106 that can serve as a host device 104 according to certain embodiments. For example, the host device 104 can utilize a non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes a host dynamic random access memory (DRAM) 138. In some examples, the storage system 100 can include multiple storage devices that can operate as a storage array, such as the data storage device 106. For example, the storage system 100 can include multiple data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID), and the multiple data storage devices together serve as a mass storage device for the host device 104.
[0025] The host device 104 can store data to and / or retrieve data from one or more storage devices such as the data storage device 106. As Figure 1As shown, the host device 104 can communicate with the data storage device 106 via the interface 114. The host device 104 can include any of a wide range of devices, including: computer servers, network attached storage (NAS) units, desktop computers, notebooks (i.e., laptops) computers, tablets, set-top boxes, telephone handsets (such as so-called "smart" phones, so-called "smart" tablets), televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices capable of sending or receiving data from the data storage device.
[0026] The host DRAM 138 can optionally include a host memory buffer (HMB) 150. The HMB 150 is a portion of the host DRAM 138 that is allocated to the data storage device 106 for exclusive use by the controller 108 of the data storage device 106. For example, the controller 108 can store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, etc. in the HMB 150. In other words, the HMB 150 can be used by the controller 108 to store data that would typically be stored in volatile memory 112, buffer 116, the internal memory of the controller 108 such as static random access memory (SRAM), etc. In an example where the data storage device 106 does not include DRAM (i.e., optional DRAM 118), the controller 108 can utilize the HMB 150 as the DRAM of the data storage device 106.
[0027] The data storage device 106 includes a controller 108, NVM 110, power supply 111, volatile memory 112, interface 114, write buffer 116, and optional DRAM 118. In some examples, the data storage device 106 can include additional components, which are not shown for clarity. Figure 1 For example, the data storage device 106 can include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and the printed circuit board includes conductive traces that electrically interconnect the components of the data storage device 106, etc. In some examples, the physical size and connector configuration of the data storage device 106 can conform to one or more standard form factors. Some example standard form factors include but are not limited to 3.5-inch data storage devices (e.g., HDD or SSD), 2.5-inch data storage devices, 1.8-inch data storage devices, peripheral component interconnect (PCI), extended PCI (PCI-X), express PCI (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe mini card, mini PCI, etc.). In some examples, the data storage device 106 can be directly coupled (e.g., directly soldered or inserted into a connector) to the motherboard of the host device 104.
[0028] Interface 114 may include one or both of a data bus for exchanging data with host device 104 and a control bus for exchanging commands with host device 104. Interface 114 may operate according to any suitable protocol. For example, interface 114 may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Fast Non-Volatile Memory (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), etc. Interface 114 (e.g., the data bus, the control bus, or both) is electrically connected to controller 108, providing an electrical connection between host device 104 and controller 108, enabling data to be exchanged between host device 104 and controller 108. In some examples, the electrical connection of interface 114 may also allow data storage device 106 to receive power from host device 104. For example, as Figure 1 shown, power supply 111 may receive power from host device 104 via interface 114.
[0029] NVM 110 may include a plurality of memory devices or memory cells. NVM 110 may be configured to store and / or retrieve data. For example, the memory cells of NVM 110 may receive data and a message indicating that the memory cell stores the data from controller 108. Similarly, the memory cell may receive a message from controller 108 indicating that the memory cell retrieves data. In some examples, each of the memory cells may be referred to as a die. In some examples, NVM 110 may include a plurality of dies (i.e., a plurality of memory cells). In some examples, each memory cell may be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB, 256 GB, 512 GB, 1 TB, etc.).
[0030] In some examples, each memory cell may include any type of non-volatile memory device such as: flash memory devices, phase change memory (PCM) devices, resistive random access memory (ReRAM) devices, magnetoresistive random access memory (MRAM) devices, ferroelectric random access memory (F-RAM), holographic memory devices, and any other type of non-volatile memory device.
[0031] The NVM 110 may include multiple flash memory devices or memory cells. The NVM flash memory devices may include NAND or NOR based flash memory devices and may store data based on the charge contained in the floating gate of the transistor of each flash memory cell. In the NVM flash memory devices, the flash memory devices may be partitioned into multiple dies, where each die of the multiple dies includes multiple physical blocks or logical blocks, and the multiple physical blocks or logical blocks may be further partitioned into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. The rows of the NVM cells may be electrically connected using word lines to define the pages within the multiple pages. The corresponding cells within each of the multiple pages may be electrically connected to corresponding bit lines. Further, the NVM flash memory devices may be 2D or 3D devices and may be single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), or quad-level cell (QLC). The controller 108 may write data to and read data from the NVM flash memory devices at the page level and erase data from the NVM flash memory devices at the block level.
[0032] The power supply 111 may supply power to one or more components of the data storage device 106. When operating in a standard mode, the power supply 111 may use the power provided by an external device such as the host device 104 to supply power to one or more components. For example, the power supply 111 may use the power received from the host device 104 via the interface 114 to supply power to one or more components. In some examples, the power supply 111 may include one or more power storage components configured to supply power to one or more components when operating in a shutdown mode, such as in the case of ceasing to receive power from an external device. In this way, the power supply 111 may be used as an on-vehicle backup power source. Some examples of the one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of electrical power that may be stored by the one or more power storage components may be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of electrical power stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.
[0033] The controller 108 may use the volatile memory 112 to store information. The volatile memory 112 may include one or more volatile memory devices. In some examples, the controller 108 may use the volatile memory 112 as a cache. For example, the controller 108 may store the information of the cache in the volatile memory 112 before the information of the cache is written to the NVM 110. As Figure 1As shown, the volatile memory 112 can consume the power received from the power supply 111. Examples of the volatile memory 112 include but are not limited to random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.)). Similarly, the optional DRAM 118 can be used to store mapped data, buffered commands, logical-to-physical (L2P) tables, metadata, cached data, etc. in the optional DRAM 118. In some examples, the data storage device 106 does not include the optional DRAM 118, such that the data storage device 106 is DRAM-less. In other examples, the data storage device 106 includes the optional DRAM 118.
[0034] The controller 108 can manage one or more operations of the data storage device 106. For example, the controller 108 can manage reading data from the NVM 110 and / or writing data to the NVM. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 can initiate a data storage command to store the data in the NVM 110 and monitor the progress of the data storage command. The controller 108 can determine at least one operating characteristic of the storage system 100 and store the at least one operating characteristic in the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores the data in an internal memory or a write buffer 116 before sending the data associated with the write command to the NVM 110.
[0035] The controller 108 can include an optional second volatile memory 120. The optional second volatile memory 120 can be similar to the volatile memory 112. For example, the optional second volatile memory 120 can be SRAM. The controller 108 can allocate a portion of the optional second volatile memory to the host device 104 as a controller memory buffer (CMB) 122. The CMB 122 can be directly accessed by the host device 104. For example, the host device 104 can utilize the CMB 122 to store one or more submission queues that are typically maintained in the host device 104 instead of maintaining the one or more submission queues in the host device 104. In other words, the host device 104 can generate commands and store the generated commands with or without associated data in the CMB 122, where the controller 108 accesses the CMB 122 to retrieve the stored generated commands and / or associated data.
[0036] As discussed herein, it is beneficial to generate files by the data storage device itself. The new method includes generating a file by the data storage device using a file mode generator and extracting the file via a vendor - specific command. The user can use the file for future use in several operations or for one - time use. The data storage device itself can identify the file via an application - specific integrated circuit (ASIC) mode engine. When a file is written to the data storage device, the data storage device will identify the file and perform internal operations indicated by the file.
[0037] Examples of internal operations include: device lock, device formatting (such as full formatting), device formatting (such as encrypted erase), device reset statistics, changing device power consumption by changing the power mode, enabling write cache, disabling write cache, adding internal storage processing steps with accelerated strong error - correcting code (ECC), adding internal storage processing steps with accelerated weak ECC, removing internal storage processing steps with accelerated strong ECC, removing internal storage processing steps with accelerated weak ECC, enabling storage device features (such as HMB), disabling storage device features (such as HMB), and flushing the cache.
[0038] The idea is to add a pattern to the file, and during the internal processing of the write command, the device itself will search for the pattern. When the pattern is found, the device will verify whether the file is valid and then read the operations from the header of the file and perform the internal operations identified in the file.
[0039] Figure 2 FIG. 10 is a schematic block diagram showing a storage system 200 having a file mode engine according to one embodiment. The storage system 200 includes a host 204, a controller 208, and a memory device (e.g., NAND) 206. The host 204 will instruct the file mode generator 214 to generate a special file for a specific internal operation. For example, the special file can be generated generally or dynamically based on a host 204 request. Once the special file is generated, the special file will be written to the storage device, such as Figure 1 the data storage device 106, via a logical block address (LBA). The special file will be forwarded to the Tx stream (control path), where the file mode engine 222 will identify the special file. The specific internal operation will be identified and executed by the file mode engine 222. The file mode engine 222 can be firmware (FW) or ASIC.
[0040] The controller 208 includes a host interface module (HIM) 212, a flash interface module (FIM) 210, multiple processors 218, a Tx stream, an Rx stream, and Tx / Rx resources 220. The HIM 212 further includes a file mode generator 214 and a direct memory access (DMA) 216. The file mode generator 214 generates special files to be used for internal operations. The Tx stream includes a file mode engine 222, an encryption unit 224, and an encoder 226. The Rx stream (data path) includes a decryption unit 228 and a decoder 230. The file mode engine 222 identifies the special files generated by the file mode generator 214.
[0041] As an example of an operation, the host 204 instructs the data storage device controller 208 to use the file mode generator 214 to generate a file for a specific operation. The specific operation can be any operation, such as formatting. The controller creates a special file for the operation via the file mode generator 214. The file is written to the data storage device LBA in the Tx path. During a future operation, the file mode engine 222 will identify the special file and retrieve the special file to perform the operation.
[0042] Figure 3 is a block diagram showing a special file format 300 according to certain embodiments. The special file format 300 includes a special file 302 which, once assigned, is subsequently considered to be the special file 304. Both the special file 302 and the special file 304 are generated by Figure 2 the file mode generator 214. When a file mode engine (such as Figure 2 the file mode engine 222) identifies a pattern in the content, the special file header will be read. The special file header helps to understand which internal operation is requested by a host (such as Figure 2 the host 204).
[0043] The special file 302 includes a special file header, a special file with internal storage tasks, and a hash-based message authentication code (HMAC) signature. The special file with internal storage tasks is located between the special file header and the HMAC signature. The HMAC signature is used to ensure the integrity of the special file for file verification.
[0044] Once the special file 302 is allocated, the special file 304 is the result. The special file 304 includes a special file header, a special file with internal storage tasks, and an HMAC signature. The special file with internal storage tasks is between the special file header and the HMAC signature. The special file 304 also includes a known header pattern, and its header pattern signature is above the special file header. The special file 304 also includes a known footer pattern, and its footer pattern signature is below the HMAC signature. Optional padding data may exist between the HMAC signature and the known footer pattern to align with the 4K flash memory buffer (FMU). The special file is the content between the known header pattern and the known footer pattern. The special file 304 can be enabled to control the device (such as Figure 1 the storage device 106) through authentication. The special file 304 can be disabled to prevent distributed denial of service (DDoS) attacks. The special file 304 may include patterns in some formats, so that the device will be filled with the required patterns. For example, for each byte 0x55, the format pattern can be stored in the special file after the header.
[0045] The device will follow the write command in the Tx stream of Figure 2 with the FMU at 4KB resolution. When the pattern is recognized by the file pattern generator 222, the special file header will be read to understand which internal operation the host 204 is requesting.
[0046] Figure 4A is a flowchart showing a method 400 for file pattern generation according to certain embodiments. The method 400 starts at block 402. At block 402, a controller (such as Figure 2 the controller 208) generates a vendor-specific file (special file) for single use or multiple uses. The file generation at block 402 is performed by Figure 2 the file pattern generator 214. At block 404, the vendor-specific file is stored for future use. When storing the vendor-specific file, the vendor-specific file is stored in a location external to the device. For example, this external location can be, but is not limited to, Figure 2 the NAND 206.
[0047] Figure 4B is a flowchart showing a method 450 for file pattern recognition according to certain embodiments. The known pattern can be protected by a signature (such as Figure 3 the HMAC signature), which can help verify the pattern. The pattern can be found by Figure 2 the file pattern engine 222. The content of the special file can be in encrypted format or plaintext format. The pattern may include a file operation identification (ID) for simply understanding the internal operation by reading the special file.
[0048] Method 450 begins at block 452. At block 452, the device recognizes that a host (such as Figure 2 204) writes a special file for internal operations. At block 454, the file mode engine 222 locates the special file. At block 456, the device verifies the special file. At block 458, the device determines whether the special file is valid. If the device determines that the special file is invalid, method 450 proceeds to block 460 to skip the internal operations. If the device determines that the special file is valid, method 450 proceeds to block 462. At block 462, the device performs internal storage device operations by reading the header file and content, such as Figure 3 shown.
[0049] The special file identification feature can be enabled or disabled by a set feature NVMe command on the host side. Method 450 operates dynamically when the device has remote access, allowing the host 204 to decide to enable or disable pattern recognition. For example, the host 204 can decide to enable or disable HMB or cache mode.
[0050] The host 204 can request to enable the special file identification feature so that the feature is not enabled by default. The feature will depend on the use case or the operation time. For example, if the operation is valid for a long time, this will be acceptable based on the set time length of the host 204. For the case where the user uses the flash cache, the user uses the special file multiple times. If the user writes a device format file, it may damage the device. The user should enable the feature of file identification to prevent security attacks.
[0051] In another example, if there is a remote server and the user (User 1) needs to lock the device remotely but User 1 cannot access the device, the special file can be the answer. Even if the server does not have administrative control or administrative permission to make the device work, the device can still be locked. A user 2 with permission can create the special file and give the special file to User 1 for one-time use to lock the device remotely. User 2 can copy the special file to a shared folder, which will then lock after User 1 runs the special file.
[0052] Figure 5 is a block diagram showing a storage system 500 that utilizes a file mode in a storage device according to some embodiments. The storage system 500 includes a host device 504, a data storage device 1 (Device 1), and a data storage device 2 (Device 2). Either Device 1 or Device 2 can be used for method 400 and method 450. In one embodiment, when Device 1 uses methods 400 and 450, then Device 2 will read the special file in Device 1 to perform internal operations. In another embodiment, when Device 2 uses methods 400 and 450, then Device 1 will read the special file in Device 2 to perform internal operations.
[0053] Figure 6 is a flow chart showing a method 600 for file pattern generation and file pattern recognition according to certain embodiments. Method 600 begins at block 602. At block 602, a controller (such as Figure 1 controller 108) receives a command from a host device to create an operation-specific file. At block 604, a file pattern engine creates an operation-specific file (special file) with an operation-specific header and signature. At block 606, a known pattern header and a known pattern footer are added to the operation-specific file. At block 608, the controller stores the operation-specific file in a first location. At block 610, the controller receives an operation-specific command from the host device. At block 612, the controller detects that the operation-specific command meets the saved operation-specific pattern. At block 614, the controller retrieves the specific file (special file) from the first location and stores the specific file in a second location. At block 616, the controller determines whether the specific file is valid. If the controller determines that the specific file is invalid, method 600 proceeds to block 618 to skip the operation. If the controller determines that the specific file is valid, method 600 proceeds to block 620. At block 620, the controller performs the operation.
[0054] The advantage of this new management control method is to perform internal storage device operations by writing files to the storage device, thereby simplifying the storage device configuration. This new method will help control several devices by using special files instead of open external tools. Using special files for management control will improve the performance of the devices. This new method simplifies the storage device configuration and controls the management commands of the devices only with input / output (I / O) accesses (such as shared folders and cloud-based storage).
[0055] In one embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a command from a host device to generate a special file for a specific operation; generate the special file; receive a request from a second data storage device to provide the special file to the second data storage device; and provide the special file to the second data storage device. The special file includes a special file header, special file internal operation tasks, and a signature. The special file includes a known header pattern and a known footer pattern. The generation occurs in a host interface module (HIM). The controller may be configured to encrypt or sign the special file. The controller is configured to check integrity using a hash message authentication code (HMAC) signature.
[0056] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a command to perform an operation from a host device; detect that the operation is an operation that includes a known pattern; request a special file related to the known pattern from a second data storage device; verify the special file; and perform the operation. The operation is selected from the group consisting of: disabling HMB support or flushing the cache. The controller is configured to read the operation from a header of the special file after verification. The controller is configured to turn on or off the detection. The known pattern includes a file operation identifier (ID). The detection is performed by a file pattern engine. The pattern engine is set along a transmission line of the controller.
[0057] In another embodiment, a data storage device includes: means for storing data; and a controller coupled to the means for storing data, wherein the controller includes: a host interface module that includes a file pattern generator; and a file pattern engine configured to identify an operation that includes a known pattern, wherein the controller is configured to: detect, using the file pattern engine, that a first command from a host device conforms to a first known pattern; retrieve a first special file from a second data storage device, wherein the first special file includes the first known pattern and a first operation associated with the first command; generate a second special file having a second known pattern different from the first known pattern, wherein the second special file is generated in response to a second command from the host device; and send the second special file to a third data storage device, wherein the first special file and the second special file can be used multiple times by other data storage devices. The first special file and the second special file each include a known header pattern and a known footer pattern. The known header pattern and the known footer pattern are different for the first special file and the second special file. The controller is configured to encrypt the second special file. The controller is configured to decrypt the first special file. The controller is configured to verify the first special file. The first special file is in volatile memory, and the second special file is in non-volatile memory.
[0058] While the foregoing is directed to embodiments of the present disclosure, other and additional embodiments of the present disclosure may be devised without departing from the basic scope thereof, and the scope of the present disclosure is determined by the appended claims.
Claims
1. A data storage device, the data storage device comprising: A memory device; And A controller, the controller being coupled to the memory device, wherein the controller is configured to: Receive from a host device a command to generate a special file for a specific operation; Generate the special file; Receive from a second data storage device a request to provide the special file to the second data storage device; And Provide the special file to the second data storage device.
2. The data storage device according to claim 1, wherein the special file includes a special file header, special file internal operation tasks, and a signature.
3. The data storage device according to claim 2, wherein the special file includes a known header pattern and a known footer pattern.
4. The data storage device according to claim 1, wherein the generation occurs in a host interface module (HIM).
5. The data storage device according to claim 1, wherein the controller is configured to encrypt or sign the special file.
6. The data storage device according to claim 5, wherein the controller is configured to use a hash message authentication code (HMAC) signature to check integrity.
7. A data storage device, the data storage device comprising: A memory device; And A controller, the controller being coupled to the memory device, wherein the controller is configured to: Receive from a host device a command to perform an operation; Detect that the operation is an operation containing a known pattern; Request from a second data storage device a special file related to the known pattern; Verify the special file; And Perform the operation.
8. The data storage device according to claim 7, wherein the operation is selected from the group consisting of: device locking, device formatting, device reset statistics, changing power mode, enabling write cache, disabling write cache, changing error correction capability, enabling host memory buffer (HMB) support, disabling HMB support, or flushing the cache.
9. The data storage device according to claim 7, wherein the controller is configured to read the operation from the header of the special file after the verification.
10. The data storage device according to claim 7, wherein the controller is configured to turn on or off the detection.
11. The data storage device according to claim 7, wherein the known pattern includes a file operation identifier (ID).
12. The data storage device according to claim 7, wherein the detection is performed by a file pattern engine.
13. The data storage device according to claim 12, wherein the pattern engine is disposed along a transmission line of the controller.
14. A data storage device, the data storage device comprising: Means for storing data; And A controller, the controller being coupled to the means for storing data, wherein the controller includes: A host interface module, the host interface module including a file pattern generator; and A file pattern engine, the file pattern engine being configured to identify an operation containing a known pattern, wherein the controller is configured to: The first command from the host device is detected by the file pattern engine to conform to a first known pattern; A first special file is retrieved from a second data storage device, where the first special file contains the first known pattern and a first operation associated with the first command; A second special file with a second known pattern different from the first known pattern is generated, where the second special file is generated in response to a second command from the host device; and The second special file is sent to a third data storage device, where the first special file and the second special file can be reused by other data storage devices multiple times.
15. The data storage device according to claim 14, wherein the first special file and the second special file each contain a known header pattern and a known footer pattern.
16. The data storage device according to claim 15, wherein the known header pattern and the known footer pattern are different for the first special file and the second special file.
17. The data storage device according to claim 14, wherein the controller is configured to encrypt the second special file.
18. The data storage device according to claim 14, wherein the controller is configured to decrypt the first special file.
19. The data storage device according to claim 14, wherein the controller is configured to verify the first special file.
20. The data storage device according to claim 14, wherein the first special file is in volatile memory, and wherein the second special file is in non-volatile memory.