GENERALIZED VERIFICATION SCHEME FOR SECURE METADATA MODIFICATION

Abstract

System and procedure for verifying the validity of a metadata modification request to prevent improper metadata operations. During the initialization of a volume in a storage device, and once a metadata area is reserved for a metadata structure, information characterizing the metadata structure and metadata area is stored in the storage device. This information may be in the form of an area legend consisting of descriptors such as a magic signature, node size, reservation clump size, and the extent of the metadata area. In response to a request to operate on metadata, the relevant information provided in the request is verified against the stored characteristic information.If the verification detects an inconsistency between the information provided in the request and the stored feature information, the request modification is treated as invalid and blocked from the operation.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to preventing metadata corruption in the field of data storage management and more particularly in the field of file systems. BACKGROUND OF THE INVENTION

[0002] File systems are used in various operating systems to organize digital files for easier storage and retrieval. File systems can manage and organize data blocks stored on a storage device into files and directories. Metadata is used by file systems to maintain information about the usage of data blocks and is often stored with the data files, such as user data, on the same storage device.

[0003] The consistency of file system metadata is critical to the operation of a file system and the accessibility of user data. Occasionally, end-user workloads can trigger inaccurate or erroneous behavior, which applies to both unstable and mature file systems. Restoring a corrupted file system volume is very time-consuming and typically involves a file system verification utility operating in an unmounted or offline state of the file system volume. This can prevent the storage device from operating efficiently and correctly, for example, by causing an unacceptable delay in data access by users and their associated application programs. Furthermore, restoring a corrupted file system volume is a nontrivial task, especially in cases of complex metadata corruption.Thus, a file system verification utility is unable to ensure file system volume consistency by restoring the file system metadata from all possible corruptions to a consistent state.

[0004] Preventing file system metadata corruption is a more promising approach to recovering a damaged file system than using a scanning utility. However, existing corruption prevention technologies undesirably and typically involve complicated logic and are specific to individual file systems and corruption causes.

[0005] US 2014 / 0 258 599 A1 discloses a data storage device including a write-protection data structure with a set of entries corresponding to a set of memory address ranges. US 2013 / 0 067 148 A1 relates to an information processing apparatus using usage attributes for semiconductor memories. US 2013 / 0 238 876 A1 relates to a mechanism for deduplicating data in a storage system. SUMMARY OF THE INVENTION

[0006] It would also be beneficial to provide a data storage system capable of maintaining metadata consistency with improved efficiency, reliability, and generality.

[0007] According to the invention, a method for managing file system metadata with verification protection, a data storage system, and a system having the features of the independent claims are provided; dependent claims relate to preferred embodiments. Embodiments of the present disclosure utilize a verification system that implements a verification process before a requested modification or other write operation to file system metadata is performed.During the initialization of a file system volume on a storage device, and once a metadata region is reserved for a metadata structure, information characterizing the metadata structure and the metadata region is stored in the storage device. This information may be in the form of a region legend consisting of descriptors such as a magic signature, a node size, a clump size for future reservations, and the extent of the metadata region. In response to a request to update the metadata stored in the metadata region, relevant information provided in the request is verified against the stored information. Furthermore, if a user data write request attempts to modify a metadata region, the modification can be prevented by verifying the stored information regarding the metadata region.Likewise, if a metadata write request attempts to modify a physical sector outside the metadata area, the modification can also be prevented by the verification process. Furthermore, improper modification of the metadata area by metadata write requests can be prevented by verification, specifically by a magic signature and / or sequential identification number of the metadata node verification.

[0008] If a verification process detects an inconsistency between the information provided in the request and the stored information, such as the metadata region legend, the request modification is treated as harmful or invalid and cannot be executed. Consequently, the stored metadata can be protected from potentially unsafe modification. A specific area in the storage device (e.g., a dedicated partition, a partition table, a special non-volatile memory chip, etc.) can be designated to store namespaces that collect the region legends for the reserved metadata regions. A request for an operation on a namespace or region legend can also be subjected to validity verification based on the values ​​of the descriptors.A verification process can be controlled and executed by software or hardware logic implemented in a host or storage device.

[0009] By using a verification system and process according to the present disclosure, a file system volume can be effectively prevented from metadata corruption, advantageously reducing or eliminating the need for a potentially time-consuming and unpredictable recovery process, as required after the fact. Furthermore, since the information on which verification is based relates to metadata structure and metadata domain characteristics, the information is inherently available in different file systems. Therefore, such a verification process is advantageously generic for different types of file systems and causes of corruption.

[0010] In one embodiment of the present disclosure, a method for verifying file system volume modifications comprises accessing, in response to a write request to modify a file system volume, stored values ​​associated with a set of descriptors characterizing a metadata structure and a reserved area for the metadata structure. The validity of the request is verified based on the request and the stored values ​​associated with the set of descriptors.

[0011] The foregoing is a summary and therefore necessarily contains simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will recognize that the summary is illustrative only and is not intended to be limiting in any way. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description provided below. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Embodiments of the present invention will be better understood by reading the following detailed description in conjunction with the accompanying figures, in which like reference numerals designate like elements and in which: Fig. 1 illustrates an exemplary verification system capable of preventing unsafe data storage content modifications according to an embodiment of the present disclosure; Fig. 2 illustrates an exemplary logical architecture that uses stored descriptors to verify write requests for metadata operations on the verified areas according to an embodiment of the present disclosure; Fig. 3A illustrates the exemplary information used to characterize metadata regions to prevent unsafe operations on the associated metadata structures according to an embodiment of the present disclosure; Fig. 3B illustrates an exemplary data structure of a namespace according to an embodiment of the present disclosure; Fig. 4 illustrates an exemplary arrangement of namespaces in a storage device according to an embodiment of the present disclosure; Fig. 5 is a flowchart illustrating an exemplary verification process in response to a write request to modify content (metadata or user data) in a file system volume according to an embodiment of the present disclosure; Fig. 6 is a flowchart illustrating an exemplary verification process in response to a request to create a namespace according to an embodiment of the present disclosure; Fig. 7A is a flowchart illustrating an exemplary verification process responsive to a request to delete a namespace associated with a partition according to an embodiment of the present disclosure; Fig. 7B is a flowchart illustrating an example verification process responsive to a request to add a range legend to a namespace according to an embodiment of the present disclosure; Fig. 8A illustrates the configuration of an exemplary data storage system with a verification subsystem residing on a host according to an embodiment of the present disclosure; Fig. 8B illustrates the configuration of another exemplary data storage system having a verification subsystem residing on a storage device according to an embodiment of the present disclosure; Fig. 9 is a block diagram illustrating an example computing system capable of preventing improper write operations to file system metadata through a verification process according to an embodiment of the present disclosure; and Fig. 10 illustrates example configurations of verification systems and processes according to embodiments of the present disclosure. DETAILED DESCRIPTION

[0013] Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it is to be understood that these are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications, and equivalents which may be included within the scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of embodiments of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be appreciated by one skilled in the art that the present invention may be practiced without these specific details.In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of embodiments of the present invention. Although a method may be presented as a sequence of numbered steps for clarity, the numbering does not necessarily dictate the order of the steps. It should be understood that some of the steps may be skipped, performed in parallel, or performed without the need to maintain a strict order of sequence. The drawings illustrating embodiments of the invention are semi-diagrammatical and not to scale, and in particular, some of the dimensions are for clarity of illustration and are exaggerated in the figures.Likewise, although the views in the drawings generally show similar orientations for ease of description, this representation in the figures is largely arbitrary. In general, the invention can be operated in any orientation. NOTATION AND NOMENCLATURE:

[0014] It should be noted, however, that all these and similar terms are associated with the corresponding physical quantities and are merely convenient labels applied to these quantities.Unless expressly noted otherwise, as will be apparent from the following discussions, it will be appreciated that throughout the present invention, discussions using terms such as "processing" or "accessing" or "executing" or "storing" or "rendering" or the like refer to the action and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities in the computer system's registers and memories and other computer-readable media into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices.When a component appears in multiple embodiments, the use of the same reference number means that the component is the same component shown in the original embodiment. GENERALIZED VERIFICATION SCHEME FOR SECURE METADATA MODIFICATION

[0015] Overall, embodiments of the present disclosure provide a verification mechanism to prevent unsafe data storage content modifications based on descriptors characterizing the metadata structure and / or metadata regions. The descriptors may be generated and stored during allocation and initialization of the metadata regions. A request to modify the data storage contents is verified against the stored descriptors related to the reserved metadata regions to determine whether the requested operation is likely to result in a metadata inconsistency.

[0016] The Fig. Figure 1 illustrates an exemplary verification system 100 capable of preventing unsafe data storage content modifications according to an embodiment of the present disclosure. As shown, the verification system 100 includes a file system driver 110, a file system volume 120 on a storage device 140, and a file system creation utility, which in this example is the MKFS utility 130. The system 100 also includes a storage driver (not shown) that cooperates with the MKFS utility 130 and the file system driver 110 to implement the verification process.

[0017] More specifically, the MKFS utility 130 creates the file system volume 120 (as shown by "(2)") by reserving and initializing storage space (e.g., metadata regions 122 and 123) for metadata structures within a partition of the storage device 140. According to the present disclosure, the MKFS utility also creates a namespace stored in the storage device (as shown by "(1)"). As described in more detail below, the namespace includes a collection of verified region legends, each verified region legend containing key information characterizing corresponding metadata regions and / or metadata structures. The namespace is stored in a dedicated partition 121 of the storage device 140 or stored in a Master Boot Record (MBR) partition table or a Globally Unique Identifier (GPT) GUID partition table.In some other embodiments, a namespace may be stored on a dedicated memory chip in a storage device (e.g., NAND flash memory). The namespace may also be encrypted, and only requests containing a secret key may access the namespace to perform namespace modification operations.

[0018] During operation, when the file system driver 110 initiates a write request to add or update a metadata record or user file stored in the file system volume 120 (as shown by "(3)"), the request is verified based on the existing region legends associated with the partition 120 (as shown by "(4)"). These existing region legends are generated, for example, during a metadata region reservation operation. If the descriptors provided in a request match the information stored as region legends, the requested operation may be performed. Whereas, if the verification process treats the requested change operation in the write request as invalid, the requested change to the file system volume may be locked.In some embodiments, a negative result from such a verification process is reported and recorded to facilitate the discovery of suspicious activities causing file system corruption.

[0019] If the file system driver 110 needs to reserve another metadata region (as indicated by "(5)"), it locates a free space on the file system volume, allocates and reserves this region internally, prepares the region legend for the reserved region, and attempts to save this legend into the namespace. Another independent subsystem (e.g., a host-side device driver or storage controller) can be used to verify the new region legend (as indicated by "(6)"). If a new region legend has a magic signature that differs from the magic signature in an existing region legend, the new region legend can be added. However, if the magic signature in the new region legend is the same as the magic signature in an existing region legend, the new region legend must be verified.On the other hand, if the verification process determines that the new scope legend is invalid, the namespace change request is treated as invalid, and the requested operation may be blocked accordingly. In some embodiments, a negative result from such a verification process is reported and recorded to facilitate the detection of suspicious activity causing file system corruption.

[0020] Thus, a verification scheme according to the present disclosure can effectively prevent corruption of the file system metadata, thereby advantageously reducing or eliminating the need for a potentially time-consuming and unpredictable recovery process required after the fact.

[0021] Fig. Figure 2 illustrates an exemplary logical architecture 200 that uses stored descriptors to verify write requests for metadata operations on verified areas 221-223, according to one embodiment of the present disclosure. Stored descriptors 230 describe verified areas 221-223 in device space 210.

[0022] It should be understood that the present disclosure is not limited to any specific type of information used to characterize a metadata structure and / or metadata region for verification purposes. Fig. 3A illustrates the exemplary information used to characterize metadata regions to prevent unsafe operations on the associated metadata structures, according to one embodiment of the present disclosure. Once the file system volume 301 is created by a file system creation utility, metadata regions within the file system volume are reserved for metadata structures. As such, each metadata region within the file system volume 301 has been defined by values ​​and can be characterized by a set of descriptors, including a magic signature, node size, clump size of possible reservations, and / or an extent.

[0023] More specifically, in the illustrated example, the magic signature 303 is a special predefined binary value that identifies a specific metadata structure. The node size 302 is a granularity of a subset of metadata elements to be placed in the metadata structure. The clump size of the reservation 305 can be a minimum, maximum, or default size of a contiguous metadata region 307. The placement of the reserved metadata region is described using the offset 306 and the size 305, e.g., with respect to the starting block and the number of blocks in the region (or the offset from the starting block).Because the information selected to characterize metadata structures and metadata regions is defined during file system volume initialization and is inherently available across file systems, the verification process that exploits this information is advantageously generic across file systems.

[0024] Those skilled in the art will recognize that the present disclosure is not limited by the format or data structure used to organize the characteristic information of metadata regions and metadata structures for verification purposes. Fig. 3B shows an exemplary namespace data structure 300 according to an embodiment of the present disclosure. In this example, the information is represented in the legends 310, 320, and 330 of the verified regions, where each legend corresponds to the metadata region reserved for a respective metadata structure. Each legend contains values ​​for a set of descriptors, namely the magic signature 311, the node size 312, the clump size of the reservation 313, and the extent 314. Because the descriptors are independent of the specifics of an individual file system and metadata content, a verification scheme based on the descriptors according to the present disclosure is generally applicable to various file systems. The verified region legends may be in extensible markup language (XML), plain text, or any other suitable format known in the art.

[0025] It is common for each file system to reside in a dedicated partition of a storage device. An aggregation of verified range legends describing all metadata areas of a specific file system volume can be stored in a partition other than the file system itself. Thus, the range legends provide an independent source of information about the file system volume. The aggregation of verified range legends is referred to here as a namespace. Fig. Figure 4 shows an exemplary arrangement of namespaces in a storage device according to an embodiment of the present disclosure. In this example, the storage device includes a plurality of partitions 1-M (e.g., 431 and 432), each associated with a respective namespace (e.g., 410 or 420). Each namespace includes the verified region legends (e.g., 411-413) describing the metadata regions in the corresponding partition.

[0026] According to the present disclosure, the characterization information contained in a namespace is used in a verification process to ensure the validity of a requested file system volume modification operation on metadata or user data. Furthermore, the information in a namespace may be edited upon request. For example, a namespace operation may add a scope legend to the namespace, remove a scope legend from the namespace, or delete an entire namespace, etc. Since improper operations in a namespace may also cause metadata inconsistency, a request to edit the namespace may be subject to a verification process according to the present disclosure, as described in more detail below.

[0027] Fig. 5 is a flowchart illustrating an exemplary verification process 500 in response to a write request to modify content (metadata or user data) in a file system volume, according to an embodiment of the present disclosure. Such a modification request is typically generated by a file system driver, a dedicated user space utility capable of modifying any physical sector in the file system volume, or a specialized user space utility capable of operating on a file system volume by extracting data or modifying file system states. During verification, the write request is analyzed to extract relevant information, which is verified against the stored mediated scope legend related to the metadata.In this example, the extracted information includes a logical block address (LBA), the presence of a known magic signature, a number of blocks, and a node size.

[0028] More specifically, at 501, it is determined whether the write request is directed to write to any metadata area based on whether the LBA specified in the request overlaps with the extent in any volume legend in the namespace. If it does not overlap, the type of the request, e.g., metadata or user data, is checked at 508. If the type of request is user data, the requested operation of writing the user data is performed according to the request at 502. However, if it does not overlap and the write request is of type metadata, the write request is determined to be invalid (at 509) and reported as an inconsistent metadata modification request.If the LBA overlaps in any way, it is determined whether the byte stream of the write request contains the same magic signature as specified in the scope legend (at 503), whether the requested number of blocks is valid for writing to the metadata area (at 504), and whether the size of the write request equals the size of one or more nodes as described in the scope legend (at 506). If any of the information provided in the request is inconsistent with the values ​​in the verified scope legend, the request is declared invalid (at 505) because it would result in a metadata inconsistency. Otherwise, the request passes verification, and the metadata is modified according to the write request at 507.

[0029] Fig. 6 is a flowchart illustrating an exemplary process responsive to a request to create a namespace according to an embodiment of the present disclosure. At 601, it is determined whether the namespace has already been created. If "yes," and if a namespace verification process is disabled (as determined at 602), the existing namespace is deleted without verification at 604, followed by confirmation of the deletion at 605. However, if the namespace already exists and the verification process is enabled, range legends in the namespace are verified prior to deletion at 603, and the deletion is confirmed at 605. A process attempting to delete legends in the namespace prepares the same set of range legends based on knowledge of the file system volume internals.If the prepared set of scope legends does not match the scope legends contained in the namespace to be deleted, the verification process may discard the delete operation.

[0030] On the other hand, if the namespace to be created does not exist (as determined in 601), it is determined at 606 whether namespace verification should be enabled. If it is not enabled, the namespace's scope legends are added at 608. At 609, it is checked whether all scope legends have been added. However, if namespace verification should be enabled (as determined in 606), the verification mechanism is activated at 607, for example, by setting a flag or in any other suitable manner well known in the art.

[0031] After metadata structures in a file system volume are created by the file system creation utility, the associated namespace may be deleted or otherwise modified. According to the present disclosure, a namespace verification process may be used to protect the namespace from improper operations. According to embodiments of the present disclosure, a namespace includes an identification number, all magic signatures for the created verified areas, and all of their node sizes. Upon receipt of a namespace deletion request, a namespace verification process is performed to determine whether the namespace content is correctly described in the deletion request and, accordingly, determines the validity of the deletion request.

[0032] Fig. 7A is a flowchart illustrating an exemplary verification process 700 in response to a request to delete a namespace associated with a partition according to an embodiment of the present disclosure. The request may be generated based on a user request or an application program. For example, the process 700 may be executed upon execution of block 603 in Fig. 6. In some embodiments, the request to delete a namespace may be based on a request to create a namespace, as described with reference to Fig. 6. In the verification process 700, the scope legends prepared by the process attempting to delete the namespace are reviewed. The scope legends are prepared based on knowledge of the file system internals. Then, a verification process compares existing scope legends with the prepared ones.

[0033] More specifically, at 701, it is determined whether the request provides a valid namespace identification number. If not, the request is discarded at 702. If the request provides a valid namespace identification number, it is further determined whether the namespace contains magic 703, the request provides valid node sizes 704, and the request provides all magic signatures of the metadata structures 705. If any of the information is determined to be inconsistent with the stored namespace, the namespace deletion request is declared invalid and may be discarded at 702. Otherwise, the namespace is deleted at 706.

[0034] Fig. 7B is a flowchart illustrating an exemplary verification process 750 responsive to a request to add a range legend to a namespace according to an embodiment of the present disclosure. At 751, it is determined whether the namespace contains a legend with the magic signature provided in the request. If the namespace does not have such a magic signature, at 752, a new legend may be added and requested without further verification. Otherwise, at 753, the node size in the existing legend with the magic signature is compared to the node size of the legend to be added. If the node sizes do not match, at 755, the range legend specified in the request is treated as invalid and cannot be added to the namespace. If the node sizes match, at 754, the extent in the legend to be allocated is compared with a lump size of the reservation (e.g.,a minimum, default, or maximum size). If the extent is equal to the minimum, default, or maximum clump size of the reservation, the scope legend is added to the namespace at 752. Otherwise, the scope legend specified in the request is treated as invalid at 755.

[0035] A verification mechanism according to the present disclosure may be implemented as software, hardware, or a combination thereof on a storage device (e.g., a hard disk drive) and / or a host (computer or data storage system). Furthermore, a verification mechanism may be used in a local file system or a distributed file system. In some embodiments, the data storage system is a single computing device, where the verification system may be a dedicated operating system utility or a dedicated application program. In some other embodiments, the verification system is integrated into an operating system, a file system creation utility, or an application program. In still some other embodiments, the data storage system is a server-client system having a file system server coupled to a storage device.

[0036] Fig. 8A illustrates the configuration of an exemplary data storage system 800 with a verification subsystem 813 residing on a host 810 according to an embodiment of the present disclosure. The host 810 includes the file system driver 811, which initiates read / write requests to the block-tier subsystem 812. The block-tier subsystem 812 may convert the file system read / write requests into Small Computer System Interface (SCSI) / Serial Advanced Technology Attachment (SATA) packets. The verification subsystem 813 may verify the file system write requests before transforming them into SCSI / SATA packets. Alternatively, the verification subsystem 813 verifies the SCSI / SATA packets received from the host's block-tier subsystem 812 (as shown). The file system volume and associated verified extent legends are stored on the storage device 820.In this configuration, the verification subsystem 813 can be managed fairly easily. For example, a user can define when verification can be active or inactive.

[0037] When the file system driver 811 issues a request to modify a file system volume or a namespace stored in the storage device 820, the verification subsystem 813 accesses the verified space legends and verifies the validity of the request, as described with reference to the Fig. 5-7B. The verified range legends may first be read from the storage device into dynamic random access memory (DRAM) during a file system installation process, so that the file system accesses the verified range legends from DRAM.

[0038] Fig. 8B illustrates the configuration of another exemplary data storage system 850 with a verification subsystem 871 residing on a storage device 870 according to an embodiment of the present disclosure. The host 860 includes the file system driver 861, which initiates read / write requests to the block layer 862. The block layer subsystem 862 transforms the file system read / write requests into SCSI / SATA packets. The verification subsystem 871 is residing on the storage device. The verification subsystem 871 includes verifying SCSI / SATA packets received from the host's block layer subsystem 862. For storage devices with limited computing power, the verification subsystem 871 is preferably implemented as a hardware module (e.g., a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)).

[0039] Fig. 9 is a block diagram illustrating an exemplary computing system 900 capable of preventing improper operations on file system metadata through a verification process according to an embodiment of the present disclosure. Computing system 900 includes a processor 901, system memory 902, a graphics processing unit (GPU) 903, input / output (I / O) interfaces 904, and network circuitry 905, an operating system 910, and application software 920. File system creation utility 921 is implemented as an application program. Operating system 910 includes file system driver 911 and a verification subsystem 912. In some other embodiments, the verification subsystem may also be implemented individually or as part of an application program. In the illustrated example, the computing system 900 is coupled to a storage device 940 via the I / O interfaces 904.Storage device 940 stores user data, metadata records, and verified region legends that characterize the metadata regions that store the metadata records of metadata structures. In some other embodiments, the storage device may be coupled to computer system 900 via network circuitry 905 and a communications network. In this case, the verification subsystem is preferably located on the storage device side.

[0040] When the configuration input is entered and executed by CPU 901, file system creation utility 921 can create a file system volume on the storage device. File system driver 911 manages user data and metadata on storage device 940. File system driver 911 can store the verified metadata scope legends on storage device 940 and initiate requests to add, delete, or otherwise modify the metadata or the verified legends. Verification subsystem 912 verifies the validity of the requests based on the verified scope legends.

[0041] In some embodiments, namespace creation and deletion processes according to the present disclosure may be integrated into the file system creation utility 921 (e.g., an MKFS utility) or separate from the file system creation utility. The file system creation utility may be responsible for populating the group descriptors in a namespace based on the file system details. In some embodiments, the file system driver communicates with the verification subsystem regarding new metadata reservations so that it can generate valid requests based on the appropriate data and the results of the verification and make changes to the namespace if necessary. In some other embodiments, new metadata space reservations are tracked based on the verification subsystem's own analysis of metadata changes in the file system volume.Thus, a verification process can be transparent to the file system driver.

[0042] The verification subsystem 912 may perform various other functions as described with reference to Fig. 1 through 8B. As will be appreciated by those skilled in the art, the present disclosure is not limited to any specific operating system. Operating system 910 may be a DOS-, Windows-, OS / 2-, Macintosh-, and Unix-based operating system, or any other operating system well known in the art.

[0043] A verification system (or subsystem) may be configured manually by a user or automatically by a software program according to the present disclosure. For example, the verification functions (including metadata verification and namespace verification) may be disabled, enabled, or customized under certain circumstances to accommodate various operational and protection circumstances. The verification logic may reside on a host side (e.g., in the block layer) or a storage side in a host storage system. It will be appreciated that the present disclosure is not limited to any specific configuration of a verification system for verifying metadata and namespace modification requests.

[0044] Fig. Figure 10 illustrates exemplary configurations of verification systems and processes according to embodiments of the present disclosure. In the illustrated examples, the verification logic and namespaces (1014, 1024, and 1034) are located on the storage device, and the file system drivers (1012, 1022, and 1032) are located on the host. However, it should be understood that the verification processes described with reference to Fig. 10 can also be implemented in systems where the verification logic and namespaces are located on a host.

[0045] In some scenarios, an available verification system may remain disabled (e.g., based on user instructions and configurations). For example, an end user may determine that the file system is trusted and request that the verification processes for metadata-related write operations be skipped. Diagram 1010 shows an example configuration of a host storage system (devices 1011 and 1013) where the verification function is universally disabled for all requests. In this configuration, any requested modification (or write operation) on the namespace 1014 or the metadata stored in the storage device 1013 is performed without verification. An example approach to bypass write operation verification is to not create namespaces when reserving metadata areas, even though the storage space for storing namespaces has been reserved on the storage device.It will be appreciated that any other suitable manner may also be used to disable metadata verification without departing from the scope of the present disclosure.

[0046] In some other scenarios, a verification system can be used to selectively verify metadata-related write requests, while namespaces can be created for all metadata. For example, requests to write to the journal area are not verified, while requests to write to the final metadata locations are verified. Diagram 1020 shows an example configuration of a host storage system (devices 1021 and 1023) where the verification function is enabled only for requests associated with an indication of the need for verification (e.g., a special marker). In this configuration, if the change request sent by the file system driver 1022 is associated with the special marker, the request is subjected to verification by the verification logic 1025. If the request is verified to be valid, the requested change is performed.This approach advantageously increases the flexibility and performance of managing an entire data storage stack.

[0047] Diagram 1030 shows an example configuration of a host storage system (1031 and 1033) where the verification function is universally enabled for all requests. In this configuration, each requested modification sent by the file system driver 1032 is verified by the verification logic 1035 to confirm its validity before execution. In particular, a requested deletion may be subject to more stringent verification, requiring proof of special authorization (e.g., in the form of a secret key provided in the request).

[0048] According to embodiments of the present disclosure, a namespace may be stored in various ways. In some embodiments, a namespace may be stored in a dedicated partition with or without encryption. Encryption may be used to further protect namespace data from unauthorized access and modification. In some other embodiments, namespace data may be stored in a special storage area in the storage device (e.g., a dedicated NAND flash chip). The special storage area, in combination with an associated special user interface, may advantageously provide better protection for the namespace data.

[0049] Although certain preferred embodiments and methods have been disclosed herein, it will be apparent to those skilled in the art from the foregoing disclosure that variations and modifications of such embodiments and methods may be made without departing from the scope of the invention. It is intended that the invention be limited only to the extent required by the appended claims and the rules and principles of applicable law.

Claims

[1] A method for managing file system metadata with verification protection, the method comprising: Receiving a first indication to verify a write operation request associated with a prescribed category; reserving a first plurality of metadata areas (122, 123, 307) in a file system volume (120), the first plurality of metadata areas configured to store a plurality of metadata sets, the plurality of metadata sets comprising a first metadata set; Creating a namespace for the reservation in response to the first indication, the namespace being stored in a particular storage area (121) of a storage device (140) and having verified area legends (310, 320, 330) containing information (311, 312, 313, 314) for characterizing a respective metadata area of ​​the first plurality of metadata areas (122, 123, 307); Receiving a first write operation request for a first write operation on the first metadata set, the first write operation request being provided with a first set of descriptors; and Verifying the first write operation request against the stored verified region legends (310, 320, 330) to determine whether to perform the first write operation, wherein it is determined whether the first set of descriptors matches information contained in the region legends, and wherein, if the first set of descriptors matches the information contained in the region legends, the first write operation may be performed. [2] The method of claim 1, wherein each write operation request associated with the prescribed category includes a flag, and further comprising identifying the flag in the first write operation request prior to verifying the first write operation request. [3] The method of claim 1, wherein the prescribed category includes all write operation requests related to the metadata records. [4] The method of claim 1, further comprising: receiving a second indication to disable verification for a write operation request in the file system; Receiving a second write operation request for a second write operation to a second metadata record; and based on the second indication, performing the second write operation without verifying the second write operation request. [5] The method of claim 4, further comprising, in response to the second indication, reserving a second plurality of metadata areas without creating a namespace associated therewith, wherein the second plurality of metadata areas comprises a metadata area for the second metadata set. [6] The method of claim 1, further comprising writing the namespace to a dedicated partition (121) of a storage device (140), the dedicated partition being separate from a partition in the storage device for storing the metadata records. [7] The method of claim 1, wherein the namespace is stored in a plain text format, a binary format, or an XML (Extensible Markup Language) format. [8] The method of claim 1, further comprising writing the namespace in a dedicated non-volatile chip separate from a storage device for storing the metadata records. [9] The method of claim 8, wherein writing comprises encrypting the namespace and wherein verifying comprises extracting a secret key from the first write operation request. [10] The method of claim 1, wherein write operation requests associated with a prescribed category are generated by a file system driver (110), and wherein verifying the first write operation request is performed on a host server in a host storage system. [11] The method of claim 10, further comprising the file system driver (110) generating a corrected first write operation request based on the verifying. [12] The method of claim 1, wherein verifying the first write operation request is performed on a storage device in a host storage system. [13] The method of claim 1, wherein a respective set of descriptors comprises one or more of the following features: magic signature; node size; reservation clump size; and extent. [14] Data storage system, comprising: one or more processors; a memory device (140) coupled to the one or more processors; and Memory coupled to the one or more processors and storing instructions that, when executed by the one or more processors, implement: a file system creation utility (130, 921) configured to: reserve a first plurality of metadata areas (122, 123, 307) in a file system volume (120) of the storage device (140), the first plurality of metadata areas (122, 123, 307) configured to store a plurality of metadata sets, the plurality of metadata sets comprising a first metadata set; a namespace utility configured to create a namespace in a particular storage area of ​​a storage device for reservation in response to a first indication, wherein the file system creation utility is further configured to create verified area legends (310, 320, 330) in the namespace containing information (311, 312, 313, 314) to characterize a respective metadata area of ​​the first plurality of metadata areas, the first indication indicating to verify a write operation request associated with a prescribed category; a file system driver (911) configured to generate write operation requests relating to the metadata areas; and Verification logic configured to: Receiving a first write operation request for a first write operation on the first metadata set, the first write operation request being provided with a first set of descriptors, and in response to the first indication, verifying the first write operation request with the stored verified region legends (310, 320, 330) to determine whether to perform the first write operation, wherein it is determined whether the first set of descriptors matches information contained in the region legends, and wherein, if the first set of descriptors matches the information contained in the region legends, the first write operation may be performed. [15] The data storage system of claim 14, wherein each write operation request associated with the prescribed category includes a tag, and further comprising identifying the tag in the first write operation request prior to verifying the first write operation request. [16] The data storage system of claim 14, wherein the prescribed category includes all write operation requests related to the metadata records. [17] The data storage system of claim 14, wherein the verification logic is further configured to: receiving a second indication to disable verification for a write operation request in the file system; Receiving a second write operation request for a second write operation to a second metadata record; and based on the second indication, performing the second write operation without verifying the second write operation request. [18] The data storage system of claim 17, wherein the namespace utility is further configured, in response to the second indication, to refrain from creating a namespace associated therewith while reserving a second plurality of metadata areas, the second plurality of metadata areas comprising a metadata area for the second metadata set. [19] The data storage system of claim 14, wherein the namespace is stored in a dedicated partition (121) of the storage device (140), the dedicated partition being separate from a partition in the storage device for storing the metadata records. [20] The data storage system of claim 14, wherein the verification logic is located on a host (800) of the data storage system. [21] The data storage system of claim 14, wherein the verification logic is located on the storage device (870) and is implemented in a hardware circuit. [22] The data storage system of claim 14, wherein the file system driver is further configured to generate a corrected first write operation request based on the verifying. [23] System comprising: one or more processors; a memory device (140) coupled to the one or more processors; and Memory coupled to the one or more processors and storing instructions that, when executed by the one or more processors, cause the one or more processors to perform a method comprising: Receiving a first indication to verify a write operation request associated with a prescribed category; reserving a first plurality of metadata areas (122, 123, 307) in a file system volume, the first plurality of metadata areas (122, 123, 307) configured to store a plurality of metadata sets, the plurality of metadata sets comprising a first metadata set; Creating a namespace for the reservation in response to the first indication, the namespace being stored in a particular storage area (121) of a storage device (140) and having stored verified area legends (310, 320, 330) containing information (311, 312, 313, 314) to characterize a respective metadata area of ​​the first plurality of metadata areas (122, 123, 307); Receiving a first write operation request for a first write operation to the first metadata, the first write operation request being provided with a first set of descriptors; and Verifying the first write operation request with the stored verified region legends (310, 320, 330) to determine whether the first write operation should be performed, wherein it is determined whether the first set of descriptors matches information contained in the region legends, and wherein, if the first set of descriptors matches the information contained in the region legends, the first write operation may be performed. [24] The system of claim 23, wherein the prescribed category comprises all write operation requests related to the metadata records or a selected set of write operation requests related to the metadata records. [25] The system of claim 23, wherein the method further comprises: receiving a second indication to disable verification for a write operation request in the file system; Receiving a second write operation request for a second write operation to a second metadata record; and based on the second indication, performing the second write operation without verifying the second write operation request. [26] The system of claim 23, wherein the method further comprises, in response to the second indication, reserving a second plurality of metadata areas without creating a namespace associated therewith, wherein the second plurality of metadata areas comprises a metadata area for the second metadata set. [27] The system of claim 23, wherein the method further comprises generating a corrected first write operation request based on the verification.

Images