Locking method and locking apparatus for locking directory tree
The MGL method improves concurrency and reduces conflicts in file system operations by using MGL lock object arrays to track locking status across directory tree levels, optimizing memory usage and enabling simultaneous operations.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-09-27
- Publication Date
- 2026-04-02
AI Technical Summary
Existing locking mechanisms for directory trees in file systems, such as read-write locks, suffer from poor concurrency and high memory usage, leading to inefficiencies in handling concurrent operations.
Implement a Multiple Granularity Locking (MGL) method using a set of MGL lock object arrays to track locking status across multiple tree levels, allowing locks to be applied at various granularities and levels, reducing conflicts and improving concurrency.
The MGL method enables concurrent operations in file systems by minimizing lock conflicts and optimizing memory usage, enhancing the performance of filesystem metadata tree operations.
Smart Images

Figure RU2024000300_02042026_PF_FP_ABST
Abstract
Description
LOCKING METHOD AND LOCKING APPARATUS FOR LOCKING DIRECTORY TREETECHNICAL FIELD
[0001] The present disclosure relates to the field of computer technologies, and in particular, to the field of computer technologies, and in particular, to a locking method and a locking apparatus for locking a directory tree.BACKGROUND
[0002] A hierarchy of files and directories of a file system can be represented as a tree structure, i.e., a directory tree. The root node of the directory tree represents the root directory “ / ”, each intermediate node represents a subdirectory, and each leaf node represents a subdirectory or a file.
[0003] Read-write lock is a typical locking model used in related art for synchronizing filesystem operations and avoiding a current operation not being affected by other operations. If an operation requires to read the contents of a node, a read lock needs to be obtained, and if an operation requires to change the contents of a node, a write lock needs to be obtained. Read-write lock can ensure non-interference during concurrent operations, but has poor concurrency.
[0004] This background information is provided to reveal information believed by the applicant to be of possible relevance to the present disclosure. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present disclosure.SUMMARY(0005] In a first aspect, an embodiment of the present disclosure provides a locking method for locking a directory tree of a file system, implemented by a locking apparatus, comprising: obtaining an operation request; and performing, according to the operation request, a multiple-granularity locking (MGL) operation onmultiple MGL lock objects in multiple MGL lock object arrays in a set of MGL lock object arrays, where the multipleMGL lock objects in the multiple MGL lock object arrays are used for tracking current locking status of multiple nodes on multiple tree levels of the directory tree, where each tree level of the multiple tree levels corresponds to an MGL lock object array of the multiple MGL lock object arrays, and each node of the multiple nodes corresponds to an MGL lock object of the multiple MGL lock objects.
[0006] By using multiple MGL lock object arrays in a set of MGL lock object arrays to track current locking status of nodes in the directory, where each tree level of the multiple tree levels corresponds to an MGL lock object array of the multiple MGL lock object arrays, and performing an MGL operation on multiple MGL lock objects corresponding to the nodes in the directory tree, MGL locks can be applied at various levels of the directory tree and at various granularities for the operation request, and thus, MGL can be implemented for the directory tree of a file system, which allows for performing concurrent operations while reducing conflicts therebetween, thereby improving concurrency of filesystem tree operations.
[0007] In a possible implementation of the first aspect, each node in the directory tree corresponds to a respective path in the file system, and each node of the multiple nodes is mapped, based on information of a path corresponding to the respective node, to a corresponding MGL lock object in an MGL lock object array that corresponds to a tree level of the respective node. Since the nodes of the directory tree correspond to the paths in the file system respectively, each node can be mapped to a corresponding MGL lock object based on its corresponding path information. In other words, an index of an MGL lock object to which a node is mapped can be determined based on the path information of the node. In this way, the mapping between the nodes of the directory tree and the MGL lock objects can be implemented easily and effectively.
[0008] In a possible implementation of the first aspect, each of the multiple nodes is mapped, based on a hash code value of the path corresponding to the respective node and on a size of the MGL lock object array that corresponds to the tree level of the respective node, to the corresponding MGL lock object in the MGL lock object array that corresponds to the tree level of the respective node.
[0009] In a possible implementation of the first aspect, a size of each of the multiple MGL lock object arrays is preset.
[0010] In a possible implementation of the first aspect, the hash code value is obtained by using a hashing algorithm on at least one string related to the path.
[0011] Since each node corresponds to a respective path, the hash code value of the respective path can be usedto map the node to the corresponding MGL lock object. A path is generally represented by a string of characters, and the hash code value of the path may be determined by using a hashing algorithm on at least one string related to the path, which provides a possible and effective implementation for the mapping from the nodes to the MGL lock objects. In addition, this approach can allow for flexibility in the file system structure, as it can accommodate nodes with various naming conventions and path structures.|0012] In a possible implementation of the first aspect, each MGL lock object of the multiple MGL lock objects has an index which is unique in an MGL lock object array to which the respective MGL lock object belongs. Since each MGL lock object has a unique index, the nodes of the directory tree can be mapped to the MGL lock objects accurately.
[0013] In a possible implementation of the first aspect, the hash code values of nodes belonging to a same tree level are sorted ascending. This approach can ensure that threads follow a consistent order when acquiring locks, thus preventing circular wait conditions (deadlocks).
[0014] In a possible implementation of the first aspect, the directory tree includes M tree levels, where M is an integer greater than 1 and the M tree levels include the multiple node levels.
[0015] In a possible implementation of the first aspect, when M is smaller than or equal to a preset threshold N, the set of MGL lock object arrays includes M MGL lock object arrays, the M MGL lock object arrays include the multiple MGL lock object arrays, and the M MGL lock object arrays one-to-one correspond to the M tree levels. This correspondence can allow the locking mechanism to be granular, applying locks at the appropriate level of the directory structure, which can enhance concurrency by allowing multiple operations to proceed simultaneously on different levels or branches of the tree and can reduce locks collisions. Especially, since each tree level corresponds a different MGL lock object array, lock collisions between nodes of different levels can be effectively avoided. Moreover, when the number M of tree levels is less than the threshold N, only M MGL lock object arrays are needed for tracking the current locking status of the directory tree, which can avoid memory waste compared with always using N MGL lock object array regardless the number of tree levels.
[0016] In a possible implementation of the first aspect, when M is larger than a preset threshold N, the set of MGL lock object arrays includes N MGL lock object arrays, the N MGL lock object arrays include the multiple MGL lock object arrays, (N-1) MGL lock object arrays of the N MGL lock object arrays one-to-one correspond to (N-1) tree levels of the M tree levels, and one other MGL lock object array of the N MGL lock object arrays corresponds to other (M-N+l ) tree levels of the M tree levels. In this way, the locking status of the directory tree canstill be tracked by using N MGL lock object arrays even if the number of tree levels becomes greater than the maximum number N of MGL lock object arrays, and the system can handle system growth with limited memory consumption for tracking locking status.|0017] In a possible implementation of the first aspect, the (N-1) tree levels include first (N-1) consecutive tree levels of the directory tree starting from a tree level of a root node.
[0018] In a possible implementation of the first aspect, the performing, according to the operation request, the MGL operation on the multiple MGL lock objects in the multiple MGL lock object arrays includes: holding locks on the multiple MGL lock objects for the operation request, where lock modes of the locks to be held on the MGL lock objects are determined according to the operation request.
[0019] By holding locks on the MGL lock objects corresponding to the target node(s) and parent node(s) thereof according to the operation request, these nodes can be locked in appropriate modes for the operation request, thereby avoiding the operation request being interfered with by other operation request(s).
[0020] In a possible implementation of the first aspect, in a case that a lock has been held on a first MGL lock object of the multiple MGL lock objects, and a lock mode of a lock to be held on the first MGL lock object conflicts with a lock mode of the lock that has been held on the first MGL lock object, the locks are not held on the multiple MGL lock objects for the operation request until the lock that has been held on the first MGL is released.
[0021] When a lock to be held on an MGL lock object conflicts with a lock already held on the MGL lock object, locks will not be held on the multiple MLG lock objects for the operation request until the lock already held on the MGL lock object is released, thereby avoiding interference with other operation request(s) that are being processed.
[0022] In a possible implementation of the first aspect, the multiple nodes include at least one target node of the operation request and one or more parent nodes of the at least one target node.
[0023] In a possible implementation of the first aspect, in a case that the operation request indicates an operation affecting one target node, and the operation is a read operation, a share (S) lock is held on an MGL lock object corresponding to the affected target node, and an intention shared (IS) lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the affected target node.|0024] When an operation indicated by the operation request affects one target node and the operation is a read operation, an S lock is held on the MGL lock object corresponding to the affected target node, and an IS lock is held on each of the MGL lock object) s) corresponding to the parent node(s). Since the locks are held on nodes at difference levels, and the IS lock is held on the MGL lock(s) corresponding to the parent node(s), there will be more compatibleoperations that can be concurrently processed, thereby improving the concurrency of the file system.
[0025] In a possible implementation of the first aspect, in a case that the operation request indicates an operation affecting one target node, and the operation is a write operation, an exclusive (X) lock is held on an MGL lock object corresponding to the affected target node, and an intention exclusive (IX) lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the target node.
[0026] When an operation indicated by the operation request affects one target node and the operation is a write operation, an X lock is held on the MGL lock object corresponding to the affected target node, and an IX lock is held on each of the MGL lock object(s) corresponding to the parent node(s). Since the IX lock is held on the MGL lock(s) corresponding to the parent node(s), there will be more compatible operations that can be concurrently processed, thereby improving the concurrency of the file system.|0027| In a possible implementation of the first aspect, in a case that the operation request indicates an operation affecting two or more target nodes, the multiple MGL lock objects include one or more second MGL lock objects for each of which one lock mode is required, and one or more third MGL lock objects for each of which two or more lock modes are required, and a lock mode of a lock to be held on each of the one or more second MGL lock objects is determined to be the lock mode required for the respective second MGL lock object, and a lock mode of a lock to be held on each of the one or more third MGL lock objects is determined based on a greatest lock mode of the two or more lock modes required for the respective third MGL lock object.
[0028] When an operation indicated by the operation request affects two or more target nodes, there may exist one or more MGL lock objects for each of which only one lock mode is required, and there may also exist one or more other MLG lock objects for each of which two or more lock modes are required. For a MGL lock object for which one lock mode is required, the lock mode required is taken as the lock mode of the lock to be held on the MGL lock object. For a MGL lock object for which two or more lock modes are required, the greatest lock mode of the two or more lock modes is taken as the lock mode of the lock to be held on the MGL lock object. In this way, MGL can also be implemented for a complex operation which affects two or more target nodes, and a complex operation may also be concurrently performed with other compatible operations, thereby further improving concurrency of the file system.
[0029] In a possible implementation of the first aspect, in a case that the operation request indicates a write operation affecting a first target node and a read operation affecting a second target node, where the second target node is an adjacent parent node of the first target node, an exclusive (X) lock is held on an MGL lock objectcorresponding to the affected first target node, a share and intention (SIX) lock is held on an MGL lock object corresponding to the affected second target node and an intention exclusive (IX) lock is held on each of one or more MGL lock objects corresponding to one or more parent nodes of the affected first target node except the second target node.
[0030] In a possible implementation of the first aspect, in a case that a target node and one or more parent nodes of the target node include two or more nodes that are mapped to a same MGL lock object, a lock mode of a lock to be held on the same MGL lock object is determined based on lock modes required for the two or more nodes.
[0031] When two or more nodes on a path are mapped to a same MGL lock object, the lock mode of the lock to be held on that MGL lock object can be determined based on all the lock modes required for the two or more nodes, thereby avoiding the operation request being interfered with by other operation request(s).
[0032] In a second aspect, an embodiment of the present disclosure provides a locking apparatus including various modules configured to execute the locking method for locking a directory tree according to the first aspect or any possible implementation of the first aspect.
[0033] In a third aspect, an embodiment of the present disclosure provides a locking apparatus including processing circuitry for executing the locking method for locking a directory tree according to the first aspect or any possible implementation of the first aspect.
[0034] In a fourth aspect, an embodiment of the present disclosure provides a file system including the locking apparatus according to the second aspect, or the locking apparatus according to the third aspect.
[0035] In a fifth aspect, an embodiment of the present disclosure provides a file system including a metadata management component for executing the locking method for locking a directory tree according to the first aspect or any possible implementation of the first aspect.
[0036] In a sixth aspect, an embodiment of the present disclosure provides a computer-readable medium has instructions stored therein which, when executed by a processor, causes the processor to execute the locking method for locking a directory tree according to the first aspect or any possible implementation of the first aspect.
[0037] In a seventh aspect, an embodiment of the present disclosure provides a computer program product including computer execution instructions which, when executed by a processor, causes the processor to execute the locking method for locking a directory tree according to the first aspect or any possible implementation of the first aspect.
[0038] In an eighth aspect, an embodiment of the present disclosure provides a computing device, including aprocessor and a memory. The processor is connected to the memory. The memory is configured to store instructions, the processor is configured to execute the instructions. When the processor executes the instructions stored in the memory, the processor is enabled to perform the method in the first aspect or any possible design of the first aspect.
[0039] In a ninth aspect, an embodiment of the present disclosure provides a computing device cluster, including at least one computing device, where the computing device includes a processor and a memory coupled with the processor, where the memory is configured to store a computer program, and the processor is configured to invoke and run the computer program stored in the memory, so that the computing device executes the method in the first aspect or any possible design of the first aspect.
[0040] The present disclosure provides a locking method for locking a directory tree and related products. Multiple MGL lock object arrays in a set of MGL lock object arrays are used for tracking lock status of nodes in the directory tree. When an operation request is obtained, an MGL operation is performed on the MGL lock objects corresponding to the nodes in the directory tree according to the operation request. In this way, MGL locks can be applied at various levels of the directory tree and at various granularities for the operation request, and thus, MGL can be implemented for the directory tree of a file system, which allows for performing concurrent operations while reducing conflicts therebetween, thereby improving concurrency of filesystem metadata tree operationsBRIEF DESCRIPTION OF DRAWINGS
[0041] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present disclosure.
[0042] FIG. 1 is a schematic diagram of HDFS architecture.
[0043] FIG. 2 is a schematic diagram showing structure of NameNode.
[0044] FIG. 3 is a schematic diagram showing a NameNode processing workflow.
[0045] FIG. 4 is a schematic flowchart of a method for locking a directory tree according to one or more possible embodiments of the present disclosure.
[0046] FIG. 5 is a schematic diagram showing an example of a set of MGL lock object arrays according to one or more possible embodiments of the present disclosure.
[0047] FIG. 6 is a schematic diagram showing locks for a reading operation according one or more possible embodiments of the present disclosure.|0048] FIG. 7 is a schematic diagram showing locks for a writing operation according one or more possible embodiments of the present disclosure.
[0049] FIG. 8 is a schematic diagram showing locks for a snapshot operation according one or more possible embodiments of the present disclosure.
[0050] FIG. 9 is a schematic diagram showing examples of collision scenarios according one or more possible embodiments of the present disclosure.
[0051] FIG. 10 shows a schematic structural diagram of a locking apparatus according to one or more possible embodiments of the present disclosure.
[0052] FIG. 11 is a schematic diagram of an architecture of a computing device according to one or more possible embodiments of the present application.
[0053] FIG. 12 is a schematic diagram of an architecture of a computing device cluster according to one or more possible embodiments of the present application.DESCRIPTION OF EMBODIMENTS
[0054] In the following description, reference is made to the accompanying figures, which form part of the present disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and include structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.
[0055] A file system is a method of organizing files and directories on a storage medium. A distributed file system (DFS) is a file system distributed on multiple servers. DFS allows users to share files and storage over a network, and is widely used due to its high availability and scalability. A hierarchy of files and directories of a file system or DFS can be represented as a tree structure, i.e., a directory tree. The root node of the directory tree represents the root directory “ / ”, each intermediate node represents a subdirectory, and each leaf node represents a subdirectory or a file. Capability to process concurrent operations is important for the performance of the whole system, and better concurrency is especially desired for DFS which may be accessed by a large number of users or applications simultaneously
[0056] Read-write lock is a typical locking model used in related art for synchronizing filesystem operations and avoiding a current operation not being affected by other operations. If an operation requires to read the contents of a node, a read lock needs to be obtained, and if an operation requires to change the contents of a node, a write lock needs to be obtained. Read-write lock can ensure non-interference during concurrent operations.
[0057] In an existing solution, a single read-write lock is used for the whole metadata tree. This solution has a simple implementation, but has poor concurrency since the whole metadata tree will be locked for each metadata tree operation and no other operation can be performed concurrently.
[0058] In another solution, read-write locks are added for every nodes of the metadata tree involved into the operation. Specifically, a fixed size array of read-write locks is applied per level of metadata tree. Canonical path of a destination object is split into directories and the lock on each level is held based on the directory name. Lock mode depends upon requested operation. For any read operation, a read lock is held for all nodes involved in the operation, while for any create / delete operation, a write lock is held for the parent node and a read lock is held for other higher nodes. This solution can provide better concurrency than the signal read-write lock solution. However, for operations that modify the content of the directory, a write lock is applied on the parent node and thus, any other parallel actions inside the directory will be blocked. In addition, this solution is not suitable for real life, because it significantly increases random access memory (RAM) usage by metadata tree.
[0059] In another solution, a fixed-size array of MGL is used to track locking status of nodes in a directory. This solution can provide better concurrency for operations within the same directory than previous solutions but may cause collisions of lock objects for different directories which degrades the performance especially on upper levels of a file system tree.
[0060] The present disclosure provides a locking solution which can improve the performance of parallel operations with the file system metadata tree stored in memory by using a set of multiple granularity lock arrays. Hadoop Distributed File System (HDFS) is taken as an example in the following to describe the solution of the present disclosure. However, the solution is applicable for any file system, which stores the working set of data in memory in tree-like structure and performs concurrent modifications of different sub trees. Generally, this solution can be applied for synchronizing of concurrent metadata tree operations of any filesystem either distributed or local provided that metadata tree is in memory.
[0061] In order to facilitate the understanding of the solution of the present disclosure, some terms mentioned in the present disclosure are first introduced.
[0062] Multiple Granularity Locking (MGL) is a locking method where locks are set on objects that contain other objects. MGL exploits the hierarchical nature of the containing relationship. For example, a database may have files, which contain pages, which contain records. This can be thought of as a tree of objects, where each node contains its children. A lock on this structure (such as a shared or exclusive lock) locks the targeted node as well as all of its descendants.
[0063] Hadoop Distributed File System (HDFS) is a distributed file system designed to run on commodity hardware. It has many similarities with existing distributed file systems.
[0064] HDFS is highly fault-tolerant and is designed to be deployed on low-cost hardware.
[0065] HDFS provides high throughput access to application data and is suitable for applications that have large data sets.
[0066] HDFS relaxes a few Portable Operating System Interface (POSIX) requirements to enable streaming access to file system data.
[0067] HDFS was originally built as infrastructure for the Apache Nutch web search engine project.
[0068] HDFS is part of the Apache Hadoop Core project.
[0069] HDFS NameNode is a master server that manages the file system namespace and regulates access to files by clients, and executes file system namespace operations like opening, closing, and renaming files and directories. It also determines the mapping file data blocks to DataNodes. The simplest HDFS configuration includes one NameNode instance and several DataNodes.
[0070] HDFS DataNode manages storage attached to the nodes that they run on. HDFS exposes a file system namespace and allows user data to be stored in files. Internally, a file is split into one or more blocks and these blocks are stored in a set of DataNodes.
[0071] The DataNodes are responsible for serving read and write requests from the file system’s clients.
[0072] The DataNodes also perform block creation, deletion, and replication upon instruction from theNameNode.
[0073] MapReduce is a programming paradigm that enables massive scalability across hundreds or thousands of servers in a Hadoop cluster. As the processing component, MapReduce is the heart of Apache Hadoop. The term "MapReduce" refers to two separate and distinct tasks that Hadoop programs perform.|0074] INode is a data structure in a Unix-style file system that describes a file-system object such as a file or a directory.
[0075] INode ID is unique identifier of INode object.
[0076] Data block is a chunk with fixed size where HDFS stores file content.
[0077] Fslmage is a file stored on the operating system (OS) filesystem that contains the complete directory structure (namespace) of the HDFS with details about the location of the data on the data blocks and which blocks are stored on which DataNode.
[0078] EditLogs is a transaction log that records the changes in the HDFS file system or any action performed on the HDFS cluster such as addition of a new block, replication, deletion etc. It contains the changes since the last Fslmage was created.
[0079] BlockMap is a map that maps blocks of files to their physical locations on DataNodes.
[0080] INodeMap is a map that maps INode ID and INode objects.
[0081] Canonical path is a path to a file, or a directory from the root of the file system, which contain no dot (.), double-dot (..) components nor any repeated separators ( / ) or symbolic links or reserved segments like '.reserved'.
[0082] Apache Hadoop is an open source framework that is used to store and process large datasets ranging in size from gigabytes to petabytes of data. Hadoop is an Apache project; all components are available via the Apache open source license. The main Hadoop module is distributed file system (HDFS), that was originally designed to run on standard or low-end hardware. HDFS provides better data throughput than traditional file systems, in addition to high fault tolerance and native support of large datasets. HDFS stores file system metadata and application data separately. A dedicated server, called the NameNode, is responsible for metadata storing and processing. Application data are stored on other servers called DataNodes. All servers are fully connected and communicate with each other using TCP-based protocols. HDFS can be accessed from applications in many different ways. Natively, HDFS provides a Java API for applications to use. AC language wrapper for this Java API is also available. In addition, an HTTP protocol can also be used to browse the files of an HDFS instance.
[0083] FIG. 1 is a schematic diagram of HDFS architecture. As shown in FIG. 1, HDFS consists of the following components:NameNode, which• manages the file system namespace and regulates access to files by clients• executes file system namespace operations like opening, closing, and renaming files and directories• determines the mapping of file data blocks to DataNodesDataNode, which i imanages the storage attached to the nodes that they run on• is responsible for serving read and write requests from the file system’ s clients• performs block’s creation, deletion, and replication upon instruction from the NameNode
[0084] FIG. 2 is a schematic diagram showing structure of NameNode. HDFS namespace is a hierarchy of files and directories. Files and directories are represented on the NameNode by INodes. INodes record attributes like permissions, modification and access times, namespace and disk space quotas and links to the child INodes. The file content is split into large blocks (typically 128 megabytes, but user selectable file-by-file), and each block of the file is stored on the one or more DataNodes. The NameNode maintains the namespace tree and the mapping of blocks to DataNodes.
[0085] FIG. 3 is a schematic diagram showing a NameNode processing workflow, where multiple handlers use a single global lock to process request and write changes to the EditLog file. Currently, in open-source version of Hadoop, namespace is stored in thread-unsafe tree and all operations are performed under global read-write lock. It becomes a bottleneck when there are many concurrent requests from clients. The performance can be improved by replacing tandem of thread-unsafe tree and global read-write lock with solution which allows to perform concurrent operations with different nodes if they do not conflict with each other.
[0086] FIG. 4 is a schematic flowchart of a method for locking a directory tree according to one or more possible embodiments of the present disclosure. The locking method can be implemented by a locking apparatus. Optionally, the locking apparatus can be a filesystem metadata management component that holds all metadata in memory, such as NameNode in HDFS, or other component that has similar function, which is not limited herein. As shown in FIG. 4, the locking method can include the following steps.
[0087] S410, obtain an operation request.|0088] An operation request can be obtained, which may indicate an operation to be performed. Each node in the directory tree corresponds to a respective path in the file system. The operation request may affect one or more target nodes in the directory tree. For example, if an operation request indicates reading content of / dir 1 / dir2 / , where dirl and dir2 are names of directories, the target node affected by the operation request is / dir l / dir2. For another example, if an operation request indicates creating a new file / dirl / dir2 / readme.txt, a new node is created, i.e. / dirl / dir2 / readme.txt, and the target node is the newly created node. For still another example, if an operation request indicates moving file / dirl / dir2 / readme.txt to a different folder / dir l / dir3, the node / dirl / dir2 / readme.txt will be removed and a new node / dirl / dir3 / readme.txt will be created. In this example, both the old node / dirl / dir2 / readme.txt and the new node / dirl / dir3 / readme.txt will be affected by the operation request, and there are two target nodes. Such an operation which affects two or more target nodes may also be called a “complex” operation in the present disclosure.
[0089] S420, perform, according to the operation request, a multiple-granularity locking (MGL) operation on multiple MGL lock objects in multiple MGL lock object arrays in a set of MGL lock object arrays, where the multiple MGL lock objects in the multiple MGL lock object arrays are used for tracking locking status of multiple nodes on multiple tree levels of the directory tree, each tree level of the multiple tree levels corresponds to an MGL lock object array of the multiple MGL lock object arrays, and each node of the multiple nodes corresponds to an MGL lock object of the multiple MGL lock objects.
[0090] A set of MGL lock object arrays including multiple arrays is used to track locking status of nodes on multiple tree levels of the directory tree. In other words, multiple MGL lock object arrays are used to hold locks on nodes on multiple tree levels of the directory tree, or paths of the file system. Since a file system may have almost unlimited height of hierarchy, made of folders, subfolders and files, the size of the array of MGL lock objects and the mapping between the nodes and MGL lock objects are important for the implementation of the solution.
[0091] When using MGL, besides a shared (S) mode, which may also be called a read mode, and an exclusive(X) mode, which may also be called a write mode, there are three additional lock modes in MGL: an intention-shared (IS) mode, which indicates explicit locking at a lower level of the tree with one or more shared locks, an intentionexclusive (IX) mode, which indicates explicit locking at a lower level with one or more exclusive locks and / or one or more shared locks, and a shared and intention-exclusive (SIX) mode, which indicates the subtree rooted by that node is locked explicitly in shared mode and explicit locking is being done at a lower level with at least one exclusive locks.
[0092] In a possible implementation, the multiple nodes may include at least one target node of the operation request and one or more parent nodes of the at least one target node. The MGL operation is performed on multiple MGL lock objects corresponding to the multiple nodes which are involved in the operation request. The multiple nodes involved in the operation request include at least one target node of the operation request and one or more parent nodes of each of the at least one target node, where the one or more parent nodes of each target node include all the parent node(s) of the target node up to the root The nodes can be mapped to the MGL lock objects based on some unique information of the nodes, which may be, for example, path information of the respective nodes.
[0093] Each tree level of the multiple tree levels of the directory tree corresponds to an MGL lock object arrayof the multiple MGL lock object arrays. That is to say, each tree level corresponds to an MGL lock object array. Different tree levels may correspond to different MGL lock object arrays of the multiple MGL lock object arrays, or may correspond to the same MGL lock object array of the multiple MGL lock object arrays. Each node of the multiple nodes corresponds to an MGL lock object of the multiple MGL lock objects
[0094] The locking method for locking a directory tree according to embodiments of the present disclosure can improve the throughput of HDFS NameNode file concurrent operations in cases when these operations don’t conflict with each other by action-path with a fixed memory usage. For example: it is possible to concurrently perform operations of creating different files in a same directory, to concurrently perform operations of reading the contents of any directories, concurrently perform an operation of moving directory A and an operation of reading the content of directory B which have different paths or some common parent directory, or perform snapshot of directory by copying the content of the directory into a subdirectory.
[0095] The solutions according to the embodiments of the present disclosure can be implemented as improvement of Hadoop NameNode by replacing one global read-write lock with MGL lock object as described in the present disclosure. Also, the solutions may also be applied to other programs which performs concurrent read / modify operations on tree-like structures.
[0096] By using multiple MGL lock object arrays in a set of MGL lock object arrays to track locking status of nodes in the directory, where each tree level of the multiple tree levels corresponds to an MGL lock object array of the multiple MGL lock object arrays, and performing an MGL operation on multiple MGL lock objects corresponding to the nodes in the directory tree, MGL locks can be applied at various levels of the directory tree and at various granularities for the operation request, and thus, MGL can be implemented for the directory tree of a file system, which allows for performing concurrent operations while reducing conflicts therebetween, thereby improving concurrency of filesystem tree operations.
[0097] In a possible implementation, each node in the directory tree may correspond to a respective path in the file system, and each node of the multiple nodes may be mapped, based on information of a path corresponding to the respective node, to a corresponding MGL lock object in an MGL lock object array that corresponds to a tree level of the respective node. FIG. 5 is a schematic diagram showing an example of a set of MGL lock object arrays according to one or more possible embodiments of the present disclosure. As shown in FIG. 5, each MGL lock object array has a fixed size. The array sizes are configured when the program starts with the value Si, S2...SN, where N is a count of arrays in the set of MGL lock object arrays, and Si= 1. Indexes of the itharray elements will then be in therange [O...Si- 1]. An Array Ai includes an MGL lock object AiLocki corresponding to a root ( / ) node. An Array Az corresponds to a first level of the directory tree (for example, / din), and the Array Az includes MGL lock objects AzLocki, AzLockz,..., A2LockS2, the MGL lock object AzLocki has 0 index in the array, and the MGL lock object A2LockSihas Sz-1 index in the array. An Array Az corresponds to a second level of the directory tree (for example, / diri / dirz), and the Array Az includes MGL lock objects AzLocki, AzLockz,..., A3LockSs, the MGL lock object AzLocki has 0 index in the array, and the MGL lock object A3LockSjhas Sz-1 index in the array. An Array AN-I corresponds to a N-2 level of the directory tree, and the Array AN-I includes MGL lock objects AN-iLocki, AN- iLockz,..., AN^Locks^, the MGL lock object AN-iLocki has 0 index in the array, and the MGL lock object / IJV.J LockSjv ihas SN-I-1 index in the array. An Array AN correspond to N-1 and greater level of the directory tree, and the Array AN includes MGL lock obj ects ANLocki , ANLOCICZ, . . . , ANLockSjv, the MGL lock obj ect ANLocki has 0 index in the array, and the MGL lock obj ect ANLockSNhas SN- 1 index in the array. When an operation is requested, such as reading from or writing to a file or directory, the system can calculate the lock indices for the affected nodes based on their paths. The system then may acquire the appropriate locks from the corresponding arrays to ensure that the operation can be performed without conflicts or data inconsistencies.
[0098] In a possible implementation, each of the multiple nodes may be mapped, based on a hash code value of the path corresponding to the respective node and on a size of the MGL lock object array that corresponds to the tree level of the respective node, to the corresponding MGL lock object in the MGL lock object array that corresponds to the tree level of the respective node. Each directory or file may be named by a string of characters based on some naming rules, where the characters may include letters, numbers or even some special characters such as Reference can be made to the ISO-9660 standard for a possible naming approach. The directory or file can be named by using other methods or standards, which does not specifically limited here. A path to a target directory may be represented by a string including names of a series of directories from the root directory to the target directory, and a path to a target file may be represented by a string including names of a series of directories from the root directory to the parent directory of the file as well as the name of the file. Since a path is generally represented by a string of characters while the index of an MGL lock object is an integer, hashing may be employed to convert the string or some other information obtained from the string to an integer value, based on which the index of the MGL lock object can be obtained. For example, the path string can be processed through a hash function to generate a hash code value. The hash code value is then used to calculate the index of the MGL lock object in the corresponding array. The calculation may involve taking the hash code value modulo the size of the MGL lock object array thatcorresponds to the tree level of the respective node to ensure the index falls within the array’s size. Therefore, a hash code value may be derived from the string and then be used for mapping a node or a path to a corresponding MGL lock object. Since the hash code value of a same path will be the same, the mapping between the nodes and MGL lock objects will not change (unless some new nodes are created, or some old nodes are removed, or the size of each of the multiple MGL lock object arrays is changed), a same node can be mapped to a same MGL lock object each time, and thus the locking status of a same node can be accurately tracked by a same MGL lock object. Then, when an operation request is obtained, the current locking status of relevant nodes can be obtained accurately, facilitating the implementation of MGL. In addition, this approach can allow for flexibility in the file system structure, as it can accommodate nodes with various naming conventions and path structures.[00991 In a possible implementation, a size of each of the multiple MGL lock object arrays may be preset. The sizes of the multiple MGL lock object arrays may be predefined based on the expected structure of the directory tree and the anticipated number of nodes at each level, and considering memory consumption for tracking locking status.
[0100] In a possible implementation, the hash code value may be obtained by using a hashing algorithm on at least one string related to the path, which provides a possible and effective implementation for the mapping from the nodes to the MGL lock objects. In a possible implementation, standard Java hashCode computation may be used to get the hash code value of the path. A hash function is designed to distribute input values (in this case, a path string) uniformly across a range of output values (in this case, a hash code). The input for the hashCode computation may be the whole string representing the path. It is also possible to represent a path as a string array of segments, starting from root (empty string), and then calculate the hash code value of the string array, for example, by using Java static method Arrays.hashCode(String[]). As an example, for a path / foo / bar, a hash code value of an array of three elements {“”, “foo”, “bar”} can be obtained. Using the segment array to obtain the hash code may reduce calculations or make the calculations more efficient. Specifically, in the solution according to the present disclosure, it is needed to calculate the hash code not only for the target node, but for all its parent nodes, starting from the root, and in the process of calculating the hash code for the segment array, the calculation is performed along this array from left to right, and as intermediate results, the hash code values of paths for all the parent nodes, starting at the root, are also obtained, and there will be no need to perform two unnecessary and heavy operations: getting the paths to all the parent nodes from the path to the target node and calculating the hash code value for each of them separately. The use of hash code value helps in evenly distributing lock requests across the MGL lock object arrays, reducing the likelihood of lock contention and improving performance.|0101] In a possible implementation, each MGL lock object of the multiple MGL lock objects may have an index which is unique in an MGL lock object array to which the respective MGL lock object belongs. Since each MGL lock object has a unique index, each node of the directory tree can be mapped to the corresponding MGL lock object accurately.
[0102] When multiple threads or transactions are operating under the same sub-tree or performing bulk operations, deadlocks can arise if locks are not managed properly. In a possible implementation, the hash code values of nodes belonging to a same tree level may be sorted ascending. Taking a canonical path / root / dirl / filel as an example, current state of all locking objects in array -Not Locked (NL). Athread 1 wants to modify content of filel. A thread 2 want to read / root / dirl and / root / dirl / filel properties (access control list (ACL) for instance). The thread 1 requires: Intention Exclusive (IX) lock on the root node, Intention Exclusive (IX) lock on / root / dirl and Exclusive (X) lock on / root / dirl / filel. The thread 2 requires: Intention Shared (IS) lock on the root node, Shared (S) lock on / root / dirl, and Shared (S) lock on / root / dirl / filel. If the order of acquiring these locks is not predefined and not sorted, it could lead to a deadlock. Specifically, the thread 1 may acquire an X lock on filel because it’s initially NL, and may attempt to acquire an IX lock on / root / dirl / dirl but cannot, as the thread 2 has already acquired an S lock on it. The thread 2 may acquire an S lock on dirl because it’s initially NL, and may attempt to acquire an S lock on filel but cannot, as the thread 1 has already acquired an X lock on file 1. In this case, a deadlock is caused. The thread 1 is holding the X lock on / root / dirl / filel and waiting for the thread 2 to release the S lock on / root / dirl, meanwhile the thread 2 is holding the S lock on / root / dirl and waiting for the thread 1 to release the X lock on file 1. To prevent such scenarios, the MGL system can sort the lock indices in ascending order before attempting to acquire locks. By sorting the locks, both threads would attempt to acquire locks starting from the root (IX for the thread 1 and IS for the thread 2), moving down the hierarchy in a predefined order. This approach can ensure that threads follow a consistent order when acquiring locks, thus preventing circular wait conditions (deadlocks).|0103] In a possible implementation, the directory tree may include M tree levels, where M is an integer greater than 1 and the M tree levels includes the multiple node levels. In a possible implementation, when M is smaller than or equal to a preset threshold N, the set of MGL lock object arrays may include M MGL lock object arrays, the M MGL lock object arrays may include the multiple MGL lock object arrays, and the M MGL lock object arrays one- to-one correspond to the M tree levels. The preset threshold N may represent a maximum number of MGL lock object arrays included in the set of MGL lock object arrays, and may be determined based on the expected complexity of the directory tree, performance requirements, memory consumption or the maximum number of levels that canbe efficiently managed by the system. When M is smaller than or equal to a preset threshold N, the number of MGL lock object arrays can be set to M, and there is a one-to-one correspondence between the M tree levels and the M MGL lock object arrays. This means that each level in the directory tree has a different MGL lock object array that is used to manage locks for operations at that level. This correspondence can allow the locking mechanism to be granular, applying locks at the appropriate level of the directory structure, which can enhance concurrency by allowing multiple operations to proceed simultaneously on different levels or branches of the tree and can reduce locks collisions. Specifically, since each tree level corresponds a different MGL lock object array, lock collisions between nodes of different levels can be effectively avoided. Moreover, when the number M of tree levels is less than the threshold N, only M MGL lock object arrays are needed for tracking the locking status of the directory tree, which can avoid memory waste compared with always using N MGL lock object array regardless the number of tree levels.
[0104] In a possible implementation, when M is larger than a preset threshold N, the set of MGL lock object arrays may include N MGL lock object arrays, the N MGL lock object arrays include the multiple MGL lock object arrays, (N-1) MGL lock object arrays of the N MGL lock object arrays one-to-one correspond to (N-1 ) tree levels of the M tree levels, and one other MGL lock object array of the N MGL lock object arrays corresponds to other (M- N+l) tree levels of the M tree levels. In a possible implementation, the (N- 1 ) tree levels may include first (N-1 ) consecutive tree levels of the directory tree starting from a tree level of a root node. Since the number of levels in a directory tree can grow dynamically, it may be more efficient to scale the system by optimizing the use of available resources rather than by continuously increasing the number of arrays. When the number of tree levels of the directory tree exceeds the preset threshold N, the (N-1) MGL lock object arrays correspond one-to-one with the first (N-1 ) levels of the directory tree. Each of the (N-1) MGL lock object arrays is responsible for managing locks at one specific level of the directory tree. The remaining levels of the directory tree correspond to the one other MGL lock object array of the N MGL lock object arrays. In this way, the locking status of the directory tree can still be tracked by using N MGL lock object arrays even if the number of tree levels becomes greater than the maximum number N of MGL lock object arrays, and the system can handle system growth with limited memory consumption for tracking locking status.
[0105] In a possible implementation, the preset threshold N may be configured and initiated when the file system starts. If the value ofN is very small, the possibility of lock collision (which refers to a situation where two or more nodes are mapped to the same MGL lock object) will be high. Although MGL may still be used in case of lockcollision as described in the following, frequent collisions may have some adverse impact on the performance of the system. In a possible implementation, the value of N may be configured according to specification of the machine(s) on which the system is running.
[0106] As an example, the set of MGL lock object arrays include N MGL lock object arrays, which are represented as Ai, Az.. - AN. The sizes of theN MGL lock object arrays Ai, A2...AN are Si, S2...SN respectively. When the number M of tree levels of the directory tree is larger than N, the lock mapping for path / din / dirV ... / dirvi-i / dirM will be illustrated as follows. First array Ai corresponds to the lock of root ( / ) path. Arrays in range Az... AN-I correspond to locks of path levels from 1 to N-2, for example: / din, / din / dirz, ..., / diri / dirz / ... / dim-2. A lock index Hi in array for itharray (where i is in range 2...N-1) can be calculated from sub-path of (i-l)thlevel:Hi = hashCode (“ / dir i / dir2 / ... / din”) mod Si
[0107] Array N (AN-I ) corresponds to locks of path levels from N- 1 to M, for example: / dir i / dir2 / ... / dim-i / dim / dim+i / dim+2 / ... / dirM. Array indices for all sub-paths are calculated as follows:HN = hashCode (“ / diri / dirz / ... / dim-i”) mod SNHN+I = hashCode (“ / din / dirz / ... / dim-i / dim”) mod SNHM-I = hashCode (“ / din / dir2 / ... / dinvi-i ”) mod SNHM = hashCode (^ISvcddxnJ ... / dirM-i / dirM”) mod SN where hashCode(s) is a function, which returns a hash code value for a given input string s.
[0108] Optionally, the values HN...HM can be sorted ascending to avoid deadlocks.
[0109] In a possible implementation, the MGL operation can be performed, according to the operation request, on the multiple MGL lock objects in the multiple MGL lock object arrays by holding locks on the multiple MGL lock objects for the operation request, where lock modes of the locks to be held on the MGL lock objects are determined according to the operation request. By holding locks on the multiple MGL lock objects corresponding to the target node(s) and parent node(s) thereof according to the operation request, these nodes can be locked in appropriate modes for the operation request, thereby avoiding the operation request being interfered with by other operation request(s).
[0110] An operation may affect one or more target nodes. Operations affecting one target node may be divided into read operations and write operations. A read operation may refer to an operation that does not change the local state of the affected target node, while a write operation may refer to an operation that changes the local state of theaffected target node, where the local state of the affected target node may include presence of the affected target node, contents of the affected target node, configurable attributes of the affected target node.10111] Presence of a node may refer to a state of whether the node exists or not. For example, an operation of creating a file / dirl / dir2 / readme.txt will lead to the creation of a new node / dirl / dir2 / readme.txt, then the node / dirl / dir2 / readme.txt is changed from not existing to existing, and the presence of the node is changed by the creation operation, and thus the creation operation is a write operation. For another example, an operation of deleting a directory / dirl / dir3 will lead to the deletion of the node / dir l / dir3, then the node / dir l / dir3 will be changed from existing to not existing, and the presence of this node is changed by the deletion operation, and thus the deletion operation is also a write operation. In yet another example, for an operation of reading the file / dir l / dir2 / readme.txt, the node / dirl / dir2 / readme.txt exists before and after the operation, and the presence of the node / dirl / dir2 / readme.txt will not be changed by this operation.
[0112] Configurable attributes may refer to those attributes that can be separately configured by an application or a user. Generally, these attributes will not automatically change along with the changes in the contents of the file or directory, and will not be changed by a read operation. For a file, the configurable attributes may include location of the file, permissions for the file, replication factor (i.e., the number of copies) of the file, etc. For a directory, the configurable attributes may include location of the directory, permissions for the directory, quotas for the directory which may include name quota for the number of names used and space quota for the amount of space used for the directoiy, etc.
[0113] If an operation does not make any change in the local state of the affected target node, for example, the operation does not create or delete the node and does not change the contents and configurable attributes of the affected target node, the operation will be a read operation. The read operation may be an operation of reading contents of a directory, an operation of reading contents of a file, an operation of opening a file, etc.
[0114] If an operation changes the local state of the affected target node, for example, the operation creates or deletes the target node, or changes the contents or a configurable attribute of the affected target node, the operation will be a write operation. The write operation may be an operation of creating a file or a directory, an operation of deleting a file or a directory, an operation of updating a file, an operation of changing permissions of a file or a directory, an operation of changing the replication factor of a file, an operation of changing quotas of a directory, etc.
[0115] In a possible implementation, the operation request indicates an operation affecting one target node, and the operation is a read operation. In such a case, an S lock is held on an MGL lock object corresponding to theaffected target node, and an IS lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the affected target node.
[0116] When an operation indicated by the operation request affects one target node and the operation is a read operation, an S lock can be held on the MGL lock object corresponding to the affected target node, and an IS lock can be held on each of the MGL lock object(s) corresponding to the affected parent node(s). For example, for an operation of reading content of / din / dir? / .. , / dirM-i / ditM, IS locks are held on all the MGL lock objects corresponding to subpaths from / to / diri / dirz / ... / dirM-i / dinn-i, and an S lock is held on the MGL lock object corresponding to / din / dirz / ... / dirM-i / ditM. For another example, when the operation is reading / din / dirs / readme.txt, an S lock is held on the MGL lock object corresponding to the target node / din / dirs / readme.txt, and IS locks are held on the MGL lock objects corresponding to the three parent nodes / , / diri, and / din / dirs. Since the locks are held on nodes at difference levels, and the IS lock is held on the MGL lock(s) corresponding to the parent node(s), there will be more compatible operations that can be concurrently processed, thereby improving the concurrency of the file system.
[0117] FIG. 6 is a schematic diagram showing locks for a reading operation according one or more possible embodiments of the present disclosure. FIG. 6 shows how the locks are held on MGL lock objects when the operation request indicates reading content of / diri / dirz / dirs / dira. 4 MGL lock object arrays (Ai, Az, As, At) in a set of MGL lock object arrays are used for tracking locking status of nodes of the directory tree. Sizes of the 4 MGL lock object arrays are 1, 4, 4, 6 respectively. The MGL lock object array Ai corresponds to a root node, the MGL lock object array Az corresponds to first level directories of the directory tree, the MGL lock object array As corresponds to second level directories of the directory tree, and MGL lock object array Aa corresponds to third level directories and fourth level directories of the directory tree. As indicated by 650 in FIG. 6, the target node / din / dirz / din / dira is mapped to the MGL lock object AaLocks. As indicated by 640, the parent node / din / dirz / dirs is mapped to the MGL lock object Aa Locks. As indicated by 630, the parent node / dir i / dir? is mapped to the MGL lock object AsLocks. As indicated by 620, the parent node / din is mapped to the MGL lock object AzLocks. And as indicated by 610, the root node / , is mapped to the MGL lock object AiLocki. Since the operation is a reading operation, an S lock is held on the MGL lock object AaLocks corresponding to the target node / din / dirz / dirs / dira, and IS locks are held on the MGL lock objects AaLocks, AsLocks, AzLockz and AiLocki corresponding to the four parent nodes / din / dirz / dirs, / dir i / di rz, / din, and / , respectively. In such a condition, since / din / dirz / dirs / dira is locked in S mode, and / din / dirz / dirs, / din / dirz, / diri, and / are locked in IS mode, then, in addition to reading operations in these five directories or other subdirectories (not shown in FIG. 6) under the five directories, some write operations, such as creating a file or adirectory, deleting a file, may also be concurrently performed in the directories / din / dirVdin, / din / din, / dir i, or in other directories such as / diri / dira (not shown in FIG. 6) under / din and other directories such as / dirs, / dire (not shown in FIG. 6) under the root path / . Therefore, there will be more compatible operations that can be concurrently processed, thereby improving the concurrency of the file system. Such processing method also applied to other reading operations.
[0118] In a possible implementation, the operation request indicates an operation affecting one target node, and the operation is a write operation. In such a case, an X lock is held on an MGL lock object corresponding to the affected target node, and an IX lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the target node.
[0119] When an operation indicated by the operation request affects one target node and the operation is a write operation, an X lock is held on the MGL lock object corresponding to the target node, and an IX lock is held on each of the MGL lock object(s) corresponding to the parent node(s). For example, for an operation of creating / diri / dirV.-. / dirM-i / dirM, IX locks are held on all the MGL lock objects corresponding to subpaths from / to / diri / dir2 / ... / dirM-i / dirM-i, and an X lock is held on the MGL lock object corresponding to / diri / dir2 / ... / dirM-i / dirM. For another example, when the operation is deleting / din / din / readme.txt, an X lock is held on the MGL lock object corresponding to the target node / din / din / readme.txt, and IX locks are held on the MGL lock objects corresponding to the three parent nodes / , / din, and / din / din. Since the IX lock is held on the MGL lock corresponding to the parent node, there will be more compatible operations that can be concurrently processed, thereby improving the concurrency of the file system.|0120] FIG. 7 is a schematic diagram showing locks for a writing operation according one or more possible embodiments of the present disclosure. FIG. 7 shows how the locks are held on MGL lock objects when the operation request indicates a writing operation on / diri / dirz / dirs / dir^ The writing operation may include creating, renaming, deleting, moving, changing, or any other modification operations. Taking the creating operation on / din / dm / din / din as an example, in such an operation, a new node / din / dir2 / din / dir4 is created and taken as the target node. As indicated by 750, the target node / din / dir^din / din is mapped to the MGL lock object AiLocks. As indicated by 740, the parent node / din / dirVdirr is mapped to the MGL lock object AiLocfa. As indicated by 730, the parent node / din / din is mapped to the MGL lock object AsLocki. As indicated by 720, the parent node / din is mapped to the MGL lock object AzLocle. And as indicated by 710, the root node / , is mapped to the MGL lock object AiLocki. Since the operation is a creating operation, which changes the local state of the target node, an X lock is held on the MGL lockobject A4Locks corresponding to the target node / din / dir2 / din / dir4, and IX locks are held on the MGL lock objects AJ.ocka, AjLocka, AzLocle and AiLocki corresponding to the four parent nodes / din / dirVdin, / dir i / din, / dir i, and / , respectively. In such a condition, since / diri / dir:z / dir3, / din / din, / din, and / are locked in IX mode, then, reading operations such as reading a directory or a file, or changing operations such as creating a file or a directory, deleting a file, may be concurrently performed in other directories such as / dir i / dirz / din / dir? (not shown in FIG. 7) under the directory / din / dirz / dirs or in other directories such as / din, / dire (not shown in FIG. 7) under the root directory Therefore, there will be more compatible operations that can be concurrently processed, thereby improving the concurrency of the file system.|0121] In a possible implementation, a lock has been held on a first MGL lock object of the multiple MGL lock objects, and a lock mode of a lock to be held on the first MGL lock object conflicts with a lock mode of the lock that has been held on the first MGL lock object. In such a case, the locks are not held on the multiple MGL lock objects for the operation request until the lock that has been held on the first MGL is released.]0122] When a lock to be held on an MGL lock object conflicts with a lock already held on the MGL lock object, the operation request needs to wait for other operation(s) to release the lock already held on the MGL lock object, and the locks will not be held on the multiple MLG lock objects for the operation request until the lock already held on the MGL lock object is released, thereby avoiding interference with other operation requests) that are being processed.
[0123] The MGL operation should follow the compatibility matrix as shown in table 1, where “> / ” indicates the two lock modes are compatible with each other, while “x” indicates that the two lock modes conflict with each other.Table 1
[0124] In a possible implementation, the operation request may indicate an operation affecting two or more target nodes. In this case, the multiple MGL lock objects may include one or more second MGL lock objects foreach of which one lock mode is required, and one or more third MGL lock objects for each of which two or more lock modes are required, and a lock mode of a lock to be held on each of the one or more second MGL lock objects is determined to be the lock mode required for the respective second MGL lock object, and a lock mode of a lock to be held on each of the one or more third MGL lock objects is determined based on a greatest lock mode of the two or more lock modes required for the respective third MGL lock object. In this way, MGL can also be implemented for a complex operation which affects two or more target nodes, and a complex operation may also be concurrently performed with other compatible operations, thereby further improving concurrency of the file system.Table 2
[0125] When the operation request indicates an operation affecting two or more target nodes, which for example, may be a move operation, a rename operation, a snapshot operation, etc., more than one lock modes may be required for a single node. In the multiple MGL lock objects, there may exist one or more MGL lock objects for each of which only one lock mode is required, and there may also exist one or more other MLG lock objects for each of which two or more lock modes are required. For a MLG lock object for which one lock mode is required, the lock mode required can be taken as the lock mode of the lock to be held on the MGL lock object. For a MGL lock object for which two or more lock modes are required, the lock mode of the lock to be held on the MGL lock object can be determined by summarizing all the lock modes required for the MGL lock object. Summarizing or adding of the lock modes follows the lock mode arithmetic as shown in table 2.
[0126] Some examples of complex operations will be described to facilitate understanding of the solutions of the locking method for locking a directory tree according to the present disclosure.
[0127] In an example, the operation request may indicate HDFS snapshot which performs simultaneous read and write operations in the same directory. For example, for taking a snapshot of / din / dir? / ... / dinn-i / dirM, a special destination directory / din / dir2 / ... / dirM-i / dir . snapshot is created inside the source one / din / dir? / ... / dirM i / dirxi / . Inthis case, both / din / dirz / ... / dirM-i / dirM and / din / dirz / ... / dirM-i / dirM / .snapshot are target nodes. An S lock is required for the target node / din / dirz / ... / ditM-i / dirM of which the content is read, and IS locks are required for its parent nodes from / to / din / dirz / ... / dinn-i. An X lock is required for the target node / dir i / dirs / ... / dirM-i / dirM / .snapshot which is the destination node for the operation, and IX locks are required for its parent nodes from / to / diri / dir2 / ... / ditM. Then, locks will be held as follows:X lock for destination path / din / dirz / ... / dirM-i / dirM / .snapshotS lock + IX lock = SIX lock for path / din / dirz / ... / dinn-i / dirMIS lock + IX lock = IX lock for all sub-paths from / to / dir i / dirz / ... / dirM-i.[0128| In a possible implementation, the operation request may indicate a write operation affecting a first target node and a read operation affecting a second target node, and the second target node is an adjacent parent node of the first target node, an X lock is held on an MGL lock object corresponding to the affected first target node, an SIX lock is held on an MGL lock object corresponding to the affected second target node and an IX lock is held on each of one or more MGL lock objects corresponding to one or more parent nodes of the affected first target node except the second target node.
[0129] FIG. 8 is a schematic diagram showing locks for a snapshot operation according one or more possible embodiments of the present disclosure. FIG. 8 shows how the locks are held on MGL lock objects when the operation request indicates taking an HDFS snapshot of / dir i Zdirz / dira This operation will perform simultaneous read and write operations in / din / dirz / din. As indicated by 810 in FIG. 8, the root node / is mapped to the MGL lock object AiLocki. As indicated by 820, the node / din is mapped to the MGL lock object AzLocle. As indicated by 830, the node / dir i / dirz is mapped to the MGL lock object Az Locks. As indicated by 840, the node / din / dirz / din is mapped to the MGL lock object AtLocks. And as indicated by 850, the node / din / din / din / .snapshot is mapped the MGL lock object AtLocks. The node / din / dirz / din is the target node of the read operation involved, so an S lock is required for / dir i / dirz / din, and an IS lock are required for its parent nodes / din / dirz, / din, and / . The node / din / dirz / din / .snapshot is the target node of the write operation involved, so an X lock is required for the node / din / dirz / din / .snapshot, and IX locks are required for its parent nodes / din / dirz / din, / din / dirz, / din, and I. In this case, both an S lock and an IX lock are required for the node / din / dirz / din, then a SIX lock is to be held for the node / din / dirz / din based on S+IX=SIX. Both an IS lock and an IX lock are required for the nodes / din / dirz, / din and the root node / , then an IX lock is to be held for the nodes / din / dirz, / din and the root node / based on IS+IX=IX.(0130] In another example, the operation request may indicate moving a file / din / dirz / readme .txt to a differentfolder / din / din. For this operation, the node / diri / dirVreadme.txt will be removed and a new node / din / din / readme.txt will be created. Both nodes / din / dirVrcadme.txt and / diri / din / readme.txt are affected by the operation, and thus are target nodes. X locks are required for the two target nodes since both of them are changed, where one is removed while the other is created. The target node / din / dirVreadme.txt has three parents nodes, i.e. / , / dir i, and / din / dira, for which IX locks are required. The target node / din / din / readme.txt has three parents node, i.e. / , / din, and / diri / dirs, for which IX locks are required. For each of the parent nodes / din / din and / din / din, since each of them is the parent node of one target node, only one lock is required, which is the IX lock, then the lock to be held on the corresponding MGL lock object is an IX lock. For the parent nodes / and / din, they are parents of both target nodes, then as the parent of one target node, an IX lock is required, and as the parent of the other target node, also an IX lock is required, and therefore, IX locks are to be held on the MGL lock objects corresponding to these two parent node / and / din since IX+IX=IX.
[0131] In another example, the operation request may indicate renaming a file / din / dWreadme.txt to / diri / dirVdrink.txt. For this operation, the node / din / dWreadme.txt will be removed and a new node / diri / dir2 / drink.txt will be created. Both nodes / din / dirVreadme.txt and / din / dirz / drink.txt are affected by the operation, and thus are target nodes. X locks are required for the two target nodes since both of them are changed, one is removed while the other is created. The two target nodes have three common parent nodes / , / din and / dir i / din Along with X locks for both target nodes, IX locks are required for all parent nodes of the two target nodes based on IX+IX=IX.
[0132] In some cases, when the number M of tree levels is greater than the maximum number N of arrays, N-1 and greater levels of the directory tree all correspond to the same array AN, and nodes of the N-1 and greater levels are all mapped to the MGL lock objects of the array AN. Some values of HN-I ...HM may match, which can cause a lock collision inside a single path. Such collision may occur, especially when the array size SN of array AN is of a relatively small value. Here, lock collision, which may also be called hashcode collision or mapping collision, refers to a situation where two or more nodes on a single path are mapped to a same MGL lock object due to the same hash code value. In the present disclosure, since first (N-1) levels correspond to different arrays, the nodes of a path on these levels will not be mapped to the same MGL lock object. However, since N and greater levels correspond to the same array AN, nodes of a path on these levels are mapped to MGL lock object to the same array AN, and lock collision may occur. In this case, the lock mode of the lock to be held on the MGL lock object may be determined based on the lock modes required for the two or more nodes mapped to the MGL lock object, for example, bysummarizing the lock modes required for the two or more nodes mapped to the MGL lock object. Summarizing the lock modes also follows the lock mode arithmetic as shown in table 2.
[0133] In an example, if the nodes having the same hash code value correspond to locks with the same lock mode (for example IS or IX), the structure of locks will remain the same as in the case when there is no collision. When the nodes correspond to locks with different lock modes (for example IX and X, or IS and S), the stricter level will be applied for this lock (X and S respectively) and it will correspond to the lock mode required for the node on the greater level in the directoiy tree. In this case another concurrent operation can’t hold incompatible lock on this level until it will be released.
[0134] When two or more nodes on a path are mapped to a same MGL lock object, and more than one locks modes are required for the MGL lock object, a lock of the stricter-level lock mode can be held on the MGL lock object, thereby avoiding the operation request being interfered with by other operation requests).
[0135] When two or more operations request locks on the same directory tree level, collisions may occur. For example, if two threads are requesting locks on / somedir and / someanotherdir, and these directories are at the same tree level, conflicts might arise if the calculated indices for the lock arrays are the same. Collisions may also occur when lock requests involve multiple directory tree levels. For instance, from level N onwards, all deeper locks are held in the same array. If different paths result in the same index calculation for this array, a collision may occur.
[0136] FIG. 9 is a schematic diagram showing examples of collision scenarios according one or more possible embodiments of the present disclosure. Each circle in FIG. 9 represents a node. There are two different paths shown in FIG. 9, that is a first path from / to / din / dir 10 / dir i t / diriz and a second path from / to / dir2 / dir2o / dir2i / dir22, and there are possible lock collisions for concurrent operations on the two paths. FIG. 9 shows locks required for a write operation on the first path and a read operation on the second path.
[0137] The lock collisions shown in FIG. 9 include lock collisions between directories of different paths on the same level and lock collisions between directories of different paths on different levels.
[0138] For the lock collisions between directories of different paths on the same level, as shown in FIG. 9, both the node / diri and the node / dir? are mapped to the MGL lock object AzLockz, and both the node / din / dino and the node / dir2 / dir2o are mapped to the MGL lock object Ar Locks, where IX lock is required for / di and / diri / dir io, and IS lock is required for / dir? and / dir^dirzo.
[0139] For the lock collisions between directories of different paths on different levels, as shown in FIG. 9, both the node / din / dino / dini and the node / dir2 / dir2o / dir2i / dir22 are mapped to the MGL lock object AsLocks, and both thenode / dirz / dirzo / dirz i and the node / din / dir i c / dir i i / dir 12 are mapped to the MGL lock object A^ocks, where IX lock is required for the node / din / diria / diru, S lock is required for the node Zdirz / dirzo / dirzi / dirzz, IS lock is required for the node / dirz / dirzo / dirzi and X lock is required for the node / diri / dir 10 / diri i / dir 12.
[0140] Although IX lock required for / din and / din / dirio, and IS lock required for / dirz and / dirj / dirzo are compatible with each other as shown in table 1, IX lock required for the node / din / dino / din 1 and S lock required for the node / dirz / dirzo / dirzi / dirzz are incompatible, and X lock required on / diri / dirio / diri i / diriz and IS lock required on / dira / dino / dim are incompatible either. That is to say, in the example shown in FIG. 9, the write operation on the node / dir i / dir 10 / diri i / diri 2 and the read operation on the node / dirj / dino / dim / dira cannot be performed simultaneously.
[0141] Some examples have been described to facilitate understanding of the solutions of the locking method for locking a directory tree according to the present disclosure. It should be noted that the examples are for illustration purpose only, which should not be construed as limitations to the solution of the present disclosure.
[0142] Next, embodiments of products related to the locking method for locking a directory tree will be described.
[0143] FIG. 10 shows a schematic structural diagram of a locking apparatus according to one or more possible embodiments of the present disclosure. The locking apparatus may be applied to a filesystem metadata management component that holds all metadata in memory, such as NameNode in HDFS, or other component that has similar function, which is not limited herein. As shown in FIG. 10, the locking apparatus 1000 includes: an obtaining module 1010, configured to obtain an operation request; and a processing module 1020, configured to perform, according to the operation request, a multiple-granularity locking (MGL) operation on multiple MGL lock objects in multiple MGL lock object arrays in a set of MGL lock object arrays, where the multiple MGL lock objects in the multiple MGL lock object arrays are used for tracking locking status of multiple nodes on multiple tree levels of the directory tree, where each tree level of the multiple tree levels corresponds to an MGL lock object array of the multiple MGL lock object arrays, and each node of the multiple nodes corresponds to an MGL lock object of the multiple MGL lock objects.
[0144] In a possible implementation, each node in the directory tree corresponds to a respective path in the file system, and each node of the multiple nodes is mapped, based on information of a path corresponding to the respective node, to a corresponding MGL lock object in an MGL lock object array that corresponds to a tree level of the respective node.
[0145] In a possible implementation, each of the multiple nodes is mapped, based on a hash code value of thepath corresponding to the respective node and on a size of the MGL lock object array that corresponds to the tree level of the respective node, to the corresponding MGL lock object in the MGL lock object array that corresponds to the tree level of the respective node.
[0146] In a possible implementation, a size of each of the multiple MGL lock object arrays is preset.
[0147] In a possible implementation, the hash code value is obtained by using a hashing algorithm on at least one string related to the path.
[0148] In a possible implementation, each MGL lock object of the multiple MGL lock objects has an index which is unique in an MGL lock object array to which the respective MGL lock object belongs.
[0149] In a possible implementation, the hash code values of nodes belonging to a same tree level are sorted ascending.
[0150] In a possible implementation, the directory tree includes M tree levels, where M is an integer greater than 1 and the M tree levels include the multiple node levels.
[0151] In a possible implementation, when M is smaller than or equal to a preset threshold N, the set of MGL lock object arrays includes M MGL lock object arrays, the M MGL lock object arrays include the multiple MGL lock object arrays, and the M MGL lock object arrays one-to-one correspond to the M tree levels.
[0152] In a possible implementation, when M is larger than a preset threshold N, the set of MGL lock object arrays includes N MGL lock object arrays, the N MGL lock object arrays include the multiple MGL lock object arrays, (N-1) MGL lock object arrays of the N MGL lock object arrays one-to-one correspond to (N-1) tree levels of the M tree levels, and one other MGL lock object array of the N MGL lock object arrays corresponds to other (M- N+l) tree levels of the M tree levels.
[0153] In a possible implementation, the (N-1) tree levels include first (N-1 ) consecutive tree levels of the directory tree starting from a tree level of a root node.
[0154] In a possible implementation, the processing module is configured to: hold locks on the multiple MGL lock objects for the operation request, where lock modes of the locks to be held on the MGL lock objects are determined according to the operation request.
[0155] In a possible implementation, in a case that a lock has been held on a first MGL lock object of the multiple MGL lock objects, and a lock mode of a lock to be held on the first MGL lock object conflicts with a lock mode of the lock that has been held on the first MGL lock object, the locks are not held on the multiple MGL lock objects for the operation request until the lock that has been held on the first MGL is released.
[0156] In a possible implementation, the multiple nodes include at least one target node of the operation request and one or more parent nodes of the at least one target node.
[0157] In a possible implementation, in a case that the operation request indicates an operation affecting one target node, and the operation is a read operation, an S lock is held on an MGL lock object corresponding to the affected target node, and an IS lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the affected target node.
[0158] In a possible implementation, in a case that the operation request indicates an operation affecting one target node, and the operation is a write operation, an X lock is held on an MGL lock object corresponding to the affected target node, and an IX lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the target node.
[0159] In a possible implementation, in a case that the operation request indicates an operation affecting two or more target nodes, the multiple MGL lock objects include one or more second MGL lock objects for each of which one lock mode is required, and one or more third MGL lock objects for each of which two or more lock modes are required, and a lock mode of a lock to be held on each of the one or more second MGL lock objects is determined to be the lock mode required for the respective second MGL lock object, and a lock mode of a lock to be held on each of the one or more third MGL lock objects is determined based on a greatest lock mode of the two or more lock modes required for the respective third MGL lock object.
[0160] In a possible implementation, in a case that the operation request indicates a write operation affecting a first target node and a read operation affecting a second target node, where the second target node is an adjacent parent node of the first target node, an X) lock is held on an MGL lock object corresponding to the affected first target node, an SIX lock is held on an MGL lock object corresponding to the affected second target node and an IX lock is held on each of one or more MGL lock objects corresponding to one or more parent nodes of the affected first target node except the second target node.
[0161] In a possible implementation, in a case that a target node and one or more parent nodes of the target node include two or more nodes that are mapped to a same MGL lock object, a lock mode of a lock to be held on the same MGL lock object is determined based on lock modes required for the two or more nodes.
[0162] An embodiment of the present disclosure provides a locking apparatus including processing circuitry for executing the locking method for locking a directory tree described above.
[0163] An embodiment of the present disclosure provides a file system including the locking apparatus asdescribed with reference to FIG. 10 or the locking apparatus including processing circuitry for executing the locking method for locking a directory tree described above.
[0164] An embodiment of the present disclosure provides a file system including a metadata management component for executing the locking method for locking a directory tree described above.
[0165] FIG. 11 is a schematic diagram of an architecture of a computing device according to one or more possible embodiments of the present application. The computing device 1100 can be a server or a computer or other device with computing capabilities. The computing device 1100 shown in FIG. 11 includes: a processor 1120, a memory 1130 and a bus 1110. The processor 1120 and the memory 1130 are in communication with each other via the bus 1110. The computing device 1100 can be a server or a terminal device. The present application does not limit the number of processors, and memories in the computing device 1100.
[0166] The bus 1110 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one line is used in FIG. 11, but it does not mean that there is only one bus or one type of bus. The bus 1110 may include pathways for transferring information between various components of the computing device 1100 (e.g., the memory 1130, the processor 1120, or the transceiver 1140).
[0167] The processor 1120 can include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP) processor.|0168] The memory 1130 can include volatile memory, such as RAM. The processor 1120 can also include nonvolatile memory, such as read-only memory (ROM), flash memory, a mechanical hard disk (HDD), or a solid state drive (SSD).
[0169] An executable program code is stored in the memory 1130, and the processor 1120 executes the executable program code to implement the functions of the aforementioned obtaining modulelOlO, and the processing module 1020, respectively, so as to implement the locking method for locking a directory tree described in the above embodiment. That is, the memory 1130 has instructions on it for executing the locking method for locking a directory tree described in the above embodiment.
[0170] The structure of the computing device 1100 enumerated above is only an exemplary illustration, and the present application is not limited thereto. The computing device 1100 of embodiments of the present application includes a variety of hardware found in computer systems in the prior art, e.g., the computing device 1100 also includes memory other than the memory 1130, such as, for example, a disk memory, and the like. It should beunderstood by those skilled in the art that the computing device 1100 can also include other devices necessary to achieve proper operation. In addition, depending on the specific needs, one of skill in the art should understand that the above-described computing device 1100 may also include other hardware devices for realizing other additional functions. In addition, one of skill in the art should understand that the above-described computing device 1100 may also include only the devices necessary to realize the embodiments of the present application, and need not include all of the devices shown in FIG. 11.
[0171] FIG. 12 is a schematic diagram of an architecture of a computing device cluster according to one or more possible embodiments of the present application.
[0172] The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.
[0173] As shown in FIG. 12, the cluster of computing devices described includes at least one computing device 1100. The memory 1130 in one or more of the computing devices 1100 in the cluster of computing devices can hold the same instructions for performing the locking method for locking a directoiy tree described in the above embodiment.
[0174] In some possible implementations, some of the instructions for performing the locking method for locking a directory tree described in the above embodiments can also be separately held in the memory 1130 of the one or more computing devices 1100 in the cluster of computing devices. In other words, a combination of the one or more computing devices 1100 can jointly execute instructions for performing the locking method for locking a directory tree described in the above embodiment.
[0175] It is noted that the memories 1130 in the different computing devices 1100 in the cluster of computing devices can store different instructions for performing some of the functions of the computing devices 1100, respectively. That is, the instructions stored in the memories 1130 in the different computing devices 1100 can realize the functions of one or more of the obtaining module 1010, and the processing module 1020.|0176] An embodiment of the present disclosure provides a computer-readable storage medium storing computer execution instructions which, when executed by a processor, cause the processor to execute the locking method for lock a directory tree described above.
[0177] An embodiment of the present disclosure provides a computer program product including computer execution instructions which, when executed by a processor, cause the processor to execute the locking method forlocking a directory tree described above.
[0178] The embodiments set forth herein represent information sufficient to practice and illustrate ways of practicing such subject matter. Upon reading the description in light of the accompanying figures, those of skill in the art will understand the concepts of the claimed subject matter and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.
[0179] Moreover, it will be appreciated that any module, component, or device disclosed herein that executes instructions may include, or otherwise have access to, a non-transitory computer / processor readable storage medium or media for storage of information, such as computer / processor readable instructions, data structures, program modules and / or other data Anon-exhaustive list of examples of non-transitory computer / processor readable storage media includes magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, optical disks such as compact disc read-only memory (CD-ROM), digital video discs or digital versatile discs (i.e., DVDs), Blu-ray Disc™, or other optical storage, volatile and non-volatile, removable and non-removable media implemented in any method or technology, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology. Any such non- transitory computer / processor storage media may be part of a device / apparatus or accessible or connectable thereto. Computer / processor readable / executable instructions to implement a method, an application or a module described herein may be stored or otherwise held by such non-transitory computer / processor readable storage media.
[0180] In some aspects of the present disclosure, there is provided a non-transitory computer-readable medium has instructions stored therein, the instructions, when executed by a processor, may cause the processor to implement the method of the present disclosure.
[0181] In some aspects of the present disclosure, there is provided an apparatus / chipset system including at least one processor executing instructions stored in a computer-readable medium to implement the method of the present disclosure.
[0182] The present disclosure encompasses various embodiments, including not only method embodiments, but also other embodiments such as apparatus embodiments and embodiments related to non-transitory computer readable storage media Embodiments may incorporate, individually or in combinations, the features disclosed herein.
[0183] Although this disclosure refers to illustrative embodiments, this is not intended to be construed in alimiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the disclosure, will be apparent to persons skilled in the art upon reference to the description.
[0184] Features disclosed herein in the context of any particular embodiments may also or instead be implemented in other embodiments. Method embodiments, for example, may also or instead be implemented in apparatus, system, and / or computer program product embodiments. In addition, although embodiments are described primarily in the context of methods and apparatus, other implementations are also contemplated, as instructions stored on one or more non-transitory computer-readable media, for example. Such media could store programming or instructions to perform any of various methods consistent with the present disclosure.
[0185] Further, in the disclosure, the word “a” or “an” when used in conjunction with the term “including” or “including” in the claims and / or the specification may mean “one”, but it is also consistent with the meaning of “one or more”, “at least one”, and “one or more than one” unless the content clearly dictates otherwise. Similarly, the word “another” may mean at least a second or more unless the content clearly dictates otherwise. The term “and / or” herein when used in association with a list of items means any one or more of the items including that list.
Claims
CLAIMS1. A locking method for locking a directory tree of a file system, implemented by a locking apparatus, comprising: obtaining an operation request; and performing, according to the operation request, a multiple-granularity locking (MGL) operation on multiple MGL lock objects in multiple MGL lock object arrays in a set of MGL lock object arrays, wherein the multiple MGL lock objects in the multiple MGL lock object arrays are used for tracking locking status of multiple nodes on multiple tree levels of the directory tree, wherein each tree level of the multiple tree levels corresponds to an MGL lock object array of the multiple MGL lock object arrays, and each node of the multiple nodes corresponds to an MGL lock object of the multiple MGL lock objects.
2. The locking method according to claim 1 , wherein each node in the directory tree corresponds to a respective path in the file system, and each node of the multiple nodes is mapped, based on information of a path corresponding to the respective node, to a corresponding MGL lock object in an MGL lock object array that corresponds to a tree level of the respective node.
3. The locking method according to claim 2, wherein each of the multiple nodes is mapped, based on a hash code value of the path corresponding to the respective node and on a size of the MGL lock object array that corresponds to the tree level of the respective node, to the corresponding MGL lock object in the MGL lock object array that corresponds to the tree level of the respective node.
4. The locking method according to claim 3, wherein a size of each of the multiple MGL lock object arrays is preset.
5. The locking method according to claim 3 or 4, wherein the hash code value is obtained by using a hashing algorithm on at least one string related to the path.
6. The locking method according to any one of claims 3 to 5, wherein each MGL lock object of the multiple MGL lock objects has an index which is unique in an MGL lock object array to which the respective MGL lock object belongs.
7. The locking method according to claim 6, wherein the hash code values of nodes belonging to a same tree level are sorted ascending.
8. The locking method according to any one of claims 1 to 7, wherein the directory tree comprises M tree levels, wherein M is an integer greater than 1 and the M tree levels comprise the multiple node levels.
9. The locking method according to claim 8, wherein when M is smaller than or equal to a preset threshold N, the set of MGL lock object arrays comprises M MGL lock object arrays, the M MGL lock object arrays comprise the multiple MGL lock object arrays, and the M MGL lock object arrays one-to-one correspond to the M tree levels.
10. The locking method according to claims 8 or 9, wherein when M is larger than a preset threshold N, the set of MGL lock object arrays comprises N MGL lock object arrays, the N MGL lock object arrays comprise the multiple MGL lock object arrays, (N-1) MGL lock object arrays of the N MGL lock object arrays one-to-one correspond to (N-1) tree levels of the M tree levels, and one other MGL lock object array of the N MGL lock object arrays corresponds to other (M-N+l) tree levels of the M tree levels.
11. The locking method according to claim 10, wherein the (N-1) tree levels comprise first (N-1) consecutive tree levels of the directory tree starting from a tree level of a root node.
12. The locking method according to any one of claims 1 to 11, wherein the performing, according to the operation request, the MGL operation on the multiple MGL lock objects in the multiple MGL lock object arrays comprises: holding locks on the multiple MGL lock objects for the operation request, wherein lock modes of the locks to be held on the MGL lock objects are determined according to the operation request.
13. The locking method according to claim 12, wherein in a case that a lock has been held on a first MGL lock object of the multiple MGL lock objects, and a lock mode of a lock to be held on the first MGL lock object conflicts with a lock mode of the lock that has been held on the first MGL lock object, the locks are not held on the multiple MGL lock objects for the operation request until the lock that has been held on the first MGL is released.
14. The locking method according to any one of claims 1 to 13, wherein the multiple nodes comprise at least one target node of the operation request and one or more parent nodes of the at least one target node.
15. The locking method according to claim 14, wherein in a case that the operation request indicates an operation affecting one target node, and the operation is a read operation, a share (S) lock is held on an MGL lock object corresponding to the affected target node, and an intention shared (IS) lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the affected target node.
16. The locking method according to claim 14, wherein in a case that the operation request indicates an operation affecting one target node, and the operation is a write operation, an exclusive (X) lock is held on an MGLlock object corresponding to the affected target node, and an intention exclusive (IX) lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the target node.
17. The locking method according to claim 14, wherein in a case that the operation request indicates an operation affecting two or more target nodes, the multiple MGL lock objects comprise one or more second MGL lock objects for each of which one lock mode is required, and one or more third MGL lock objects for each of which two or more lock modes are required, and a lock mode of a lock to be held on each of the one or more second MGL lock objects is determined to be the lock mode required for the respective second MGL lock object, and a lock mode of a lock to be held on each of the one or more third MGL lock objects is determined based on a greatest lock mode of the two or more lock modes required for the respective third MGL lock object.
18. The locking method according to claim 14, wherein in a case that the operation request indicates a write operation affecting a first target node and a read operation affecting a second target node, wherein the second target node is an adjacent parent node of the first target node, an X lock is held on an MGL lock object corresponding to the affected first target node, a share and intention (SIX) lock is held on an MGL lock object corresponding to the affected second target node and an IX lock is held on each of one or more MGL lock objects corresponding to one or more parent nodes of the affected first target node except the second target node.
19. The locking method according to any one of claims 1 to 18, wherein in a case that a target node and one or more parent nodes of the target node comprise two or more nodes that are mapped to a same MGL lock object, a lock mode of a lock to be held on the same MGL lock object is determined based on lock modes required for the two or more nodes.
20. A locking apparatus for locking a directory tree of a file system, implemented by a locking apparatus, comprising: an obtaining module, configured to obtain an operation request; and a processing module, configured to perform, according to the operation request, a multiple-granularity locking (MGL) operation on multiple MGL lock objects in multiple MGL lock object arrays in a set of MGL lock object arrays, wherein the multiple MGL lock objects in the multiple MGL lock object arrays are used for tracking locking status of multiple nodes on multiple tree levels of the directory tree, wherein each tree level of the multiple tree levels corresponds to an MGL lock object array of the multiple MGL lock object arrays, and each node of the multiple nodes corresponds to an MGL lock object of the multiple MGL lock objects.
21. The locking apparatus according to claim 20, wherein each node in the directory tree corresponds to arespective path in the file system, and each node of the multiple nodes is mapped, based on information of a path corresponding to the respective node, to a corresponding MGL lock object in an MGL lock object array that corresponds to a tree level of the respective node.
22. The locking apparatus according to claim 21, wherein each of the multiple nodes is mapped, based on a hash code value of the path corresponding to the respective node and on a size of the MGL lock object array that corresponds to the tree level of the respective node, to the corresponding MGL lock object in the MGL lock object array that corresponds to the tree level of the respective node.
23. The locking apparatus according to claim 22, wherein a size of each of the multiple MGL lock object arrays is preset.
24. The locking apparatus according to claim 22 or 23, wherein the hash code value is obtained by using a hashing algorithm on at least one string related to the path.
25. The locking apparatus according to any one of claims 22 to 24, wherein each MGL lock object of the multiple MGL lock objects has an index which is unique in an MGL lock object array to which the respective MGL lock object belongs.
26. The locking apparatus according to claim 25, wherein the hash code values of nodes belonging to a same tree level are sorted ascending.
27. The locking apparatus according to any one of claims 20 to 26, wherein the directory tree comprises M tree levels, wherein M is an integer greater than 1 and the M tree levels comprise the multiple node levels.
28. The locking apparatus according to claim 27, wherein when M is smaller than or equal to a preset threshold N, the set of MGL lock object arrays comprises M MGL lock object arrays, the M MGL lock object arrays comprise the multiple MGL lock object arrays, and the M MGL lock object arrays one-to-one correspond to the M tree levels.
29. The locking apparatus according to claims 27 or 28, wherein when M is larger than a preset threshold N, the set of MGL lock object arrays comprises N MGL lock object arrays, the N MGL lock object arrays comprise the multiple MGL lock object arrays, (N-1) MGL lock object arrays of the N MGL lock object arrays one-to-one correspond to (N-1) tree levels of the M tree levels, and one other MGL lock object array of the N MGL lock object arrays corresponds to other (M-N+l) tree levels of the M tree levels.
30. The locking apparatus according to claim 29, wherein the (N-1) tree levels comprise first (N-1) consecutive tree levels of the directory tree starting from a tree level of a root node.
31. The locking apparatus according to any one of claims 20 to 30, wherein the processing module is configuredto: hold locks on the multiple MGL lock objects for the operation request, wherein lock modes of the locks to be held on the MGL lock objects are determined according to the operation request.
32. The locking apparatus according to claim 31, wherein in a case that a lock has been held on a first MGL lock object of the multiple MGL lock objects, and a lock mode of a lock to be held on the first MGL lock object conflicts with a lock mode of the lock that has been held on the first MGL lock object, the locks are not held on the multiple MGL lock objects for the operation request until the lock that has been held on the first MGL is released.
33. The locking apparatus according to any one of claims 20 to 32, wherein the multiple nodes comprise at least one target node of the operation request and one or more parent nodes of the at least one target node.
34. The locking apparatus according to claim 33, wherein in a case that the operation request indicates an operation affecting one target node, and the operation is a read operation, a share (S) lock is held on an MGL lock object corresponding to the affected target node, and an intention shared (IS) lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the affected target node.35 The locking apparatus according to claim 33. wherein in a case that the operation request indicates an operation affecting one target node, and the operation is a write operation, an exclusive (X) lock is held on an MGL lock object corresponding to the affected target node, and an intention exclusive (IX) lock is held on each of one or more MGL lock objects corresponding to the one or more parent nodes of the target node.
36. The locking apparatus according to claim 33, wherein in a case that the operation request indicates an operation affecting two or more target nodes, the multiple MGL lock objects comprise one or more second MGL lock objects for each of which one lock mode is required, and one or more third MGL lock objects for each of which two or more lock modes are required, and a lock mode of a lock to be held on each of the one or more second MGL lock objects is determined to be the lock mode required for the respective second MGL lock object, and a lock mode of a lock to be held on each of the one or more third MGL lock objects is determined based on a greatest lock mode of the two or more lock modes required for the respective third MGL lock object.
37. The locking apparatus according to claim 33, wherein in a case that the operation request indicates a write operation affecting a first target node and a read operation affecting a second target node, wherein the second target node is an adjacent parent node of the first target node, an X lock is held on an MGL lock object corresponding to the affected first target node, a share and intention (SIX) lock is held on an MGL lock object corresponding to the affected second target node and an IX lock is held on each of one or more MGL lock objects corresponding to oneor more parent nodes of the affected first target node except the second target node.
38. The locking apparatus according to any one of claims 20 to 37, wherein in a case that a target node and one or more parent nodes of the target node comprise two or more nodes that are mapped to a same MGL lock object, a lock mode of a lock to be held on the same MGL lock object is determined based on lock modes required for the two or more nodes.
39. A locking apparatus, comprising a processing circuitry for executing the locking method for locking a directory tree according to any one of claims 1 to 19.
40. A fde system comprising a metadata management component for executing the locking method for locking a directory tree according to any one of claims 1 to 19.
41. A computer-readable storage medium storing computer execution instructions which, when executed by a processor, cause the processor to execute the locking method for lock a directory tree according to any one of claims 1 to 19.
42. A computer program product including computer execution instructions which, when executed by a processor, cause the processor to execute the locking method for locking a directory tree according to any one of claims 1 to 19.
Citation Information
Patent Citations
Locking method and device of directory tree
CN107783988A
Directory tree operation method, file system, electronic equipment and storage medium
CN116483778A