Implementing graph search using metadata in structure of

Abstract

Techniques are described herein for a File System (GOFS) for graph organization that uses a plurality of gnode data structures and a plurality of edge entry data structures to represent a data graph. Both the gnode and the edge entry store one or more "in-structure" metadata values of the graph component characteristics. The GOFS partition includes a dedicated storage for "out-of-structure" graph component metadata values, which are accessed using graph component identifiers. Search operations may use in-structure and / or out-of-structure metadata values to efficiently identify graph search results. The search criteria may involve in-structure metadata values for both nodes and relationships. Metadata values in a structure accessing a particular search operation may be executed using an index or from within the graph component data structure itself. When the search criteria of the search operation relate to out-of-structure metadata values, generating search operation results may be performed based on accessing the dedicated metadata store using the component identifier or using the index.

Description

Technical Field

[0001] The disclosed embodiments relate to file systems, and more particularly, to a graph file system implemented in kernel space, including content nodes and relationships between nodes. Background Art

[0002] A file system defines (a) data structures used by the operating system of a computing device to store user data, and (b) user interfaces to access and manipulate the stored data. A file system typically organizes stored data into components, such as files and directories, that are arranged in a hierarchical data structure. The hierarchical data structure is defined by a root directory that serves as a mount point for the file system, where each directory in the hierarchy can store one or both of lower-level directories and / or files of any type (such as text, images, video, audio, etc.). In general, files and directories are associated with metadata (such as name, owner, timestamp of last edit, etc.) and can be relocated within the hierarchical data structure defined under the root directory.

[0003] The file system can be implemented by a single computing device, or it can be implemented using multiple computing devices by creating a virtual file system that integrates information from all devices into a single file system hierarchy. In such a multi-node system, there is a root directory, and every file that exists on the multi-node file system is logically located under the root directory. Unix-like systems can use a RAM disk or a network shared resource as the root directory of the multi-node file system.

[0004] To illustrate the hierarchical file system, Figure 1 A file system hierarchy 100 is depicted having a root directory D1 and secondary directories D11-D14 that are "located within" directory D1 (or are direct children of directory D1). File system hierarchy 100 also includes tertiary directories D21 and D22 and tertiary files F1-F7, wherein files F1-F3 are located within directory D11, file F4 is located within directory D12, directory D21 and file F5 are located within directory D13, and files F6-F7 and directory D22 are located within directory D14. For example, a user who desires to access data in file F4 may interact with hierarchy 100 via a user interface to navigate from directory D1 to directory D12 containing F4. The user may then gain access to the contents of file F4 by instructing the operating system via the user interface to "open" file F4.

[0005] File systems with hierarchically organized data structures have been the standard for operating systems for at least fifty years. Since this convention was first established, the storage and processing power of computers has increased exponentially over time, allowing users to redefine the way computing devices handle data.

[0006] Modern computer systems manage and process data with complex relationships, such as social network data, neural network data, and geographic data. Because many complex data sets cannot be neatly placed into a hierarchical data structure, complex data management can be performed using naming schemes, directory structures, or data management software run by the operating system.

[0007] To illustrate, D1 of the file system hierarchy 100 represents a particular project (such as a doctoral dissertation), and each subdirectory D11-D14 represents a particular aspect of the project (such as D11: "Draft", D12: "Research", D13: "Graphics", and D14: "Tables"). Within each subdirectory, a user can store files or additional subdirectories that represent various information related to the subject matter of the parent directory. For example, files F1-F3 each represent a draft of a thesis. The file names of these drafts can show the relationship between the files, for example, each file name ends with a version number showing the progress of the draft, or each file name indicates the corresponding part of the entire thesis document in that file.

[0008] However, complex data management strategies involving naming and / or directory conventions can be easily overlooked or confused. If conventions are not strictly followed, it can be difficult to identify the relationship between files. For example, users often identify the progression of drafts of a document by the version number appended to the end of the file name, and then create a final version annotated with the suffix "_FINAL". The user then receives feedback on this "final" draft and produces a new draft version with the suffix "_FINAL_UPDATE". Over time, although the timestamps associated with the files are different, it can be difficult to determine which of these "final" drafts is the completed draft of the document.

[0009] As described above, data management software run by an operating system can be used to represent complex data and allow users to create and manage complex data relationships. However, data management software increases the computing resources required to manage complex data because additional computing resources are required to run the software and manage any metadata repository used to store graph component properties. Many times, data management software uses a hierarchical file system to store data and accommodates more complex data relationships between stored data by utilizing supplementary information sources (such as metadata files stored in the hierarchical file system or external databases maintained by the software). As a result, data management software may require a large amount of allocated memory and storage devices. In addition, when cloud-based applications require complex data management, cloud administrators may not be able to provide data management software, or the data management software may be incompatible with the operating system of the cloud infrastructure. Therefore, compared with managing and accessing data within the file system implemented by the operating system, using data management software to manage and access data is generally more error-prone, less available, less efficient, and less cost-effective.

[0010] Thus, it would be beneficial to adapt the file system implemented by the operating system to accommodate complex data.

[0011] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any approach described in this section qualifies as prior art merely by virtue of its inclusion in this section. Furthermore, it should not be assumed that any approach described in this section is well-known, customary, or conventional merely by virtue of its inclusion in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In the attached picture:

[0013] Figure 1 Describes the file system hierarchy.

[0014] Figure 2A and 2B An example computing system is depicted.

[0015] Figure 3 Depicts an example diagram organizing file system partitions.

[0016] Figure 4 Depicted is an example gnode data structure.

[0017] Figure 5A and 5B An example diagram is depicted.

[0018] Figure 6 Depicts an example gnode table.

[0019] Figure 7A-7B Another example gnode table is depicted.

[0020] Figure 8 Depicted is an example graphical user interface that allows a user to define labels for graph components and associate those labels with properties of graph component metadata.

[0021] Fig. 9 Depicted are examples of graph-amenable data.

[0022] Fig.10 is a block diagram illustrating a computer system upon which embodiments may be implemented.

[0023] Fig.11 is a block diagram of an example basic software system that may be used to control the operation of a computer system. DETAILED DESCRIPTION

[0024] In the following description, for ease of explanation, numerous specific details are set forth in order to provide a thorough understanding of the technology described herein. However, it is apparent that the technology can be practiced without these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring the technology described herein.

[0025] 1. General Overview

[0026] This document describes techniques for a graph-organized file system (GOFS) implemented by an operating system of a computing system. GOFS represents a data graph having graph components including a plurality of nodes and one or more relationships between the nodes. Each node in the graph may be associated with content (of any kind) and / or relationships (of any kind) between the node and other nodes in the graph.

[0027] GOFS data is stored in GOFS partitions in persistent storage. In a GOFS partition, nodes are represented using "gnode" data structures (also referred to herein as "gnodes"), each of which contains a content field for node content data and an edge field for edge data representing relationships between nodes. Specifically, each relationship exists between two nodes and is represented by two edge entries in the gnode representing the relevant nodes. Each edge entry represents a single edge, which is a directional relationship component whose source is the node associated with the edge entry and whose destination is identified in the edge entry. In addition to including the destination gnode identifier of the represented edge, each edge entry also includes the name of the destination node. As described in further detail below, gnodes are similar to inodes in traditional file systems, but with some differences.

[0028] According to various embodiments, the relationship represented by the first edge entry (from node A to node B) and the second edge entry can be made unidirectional (e.g., only from node A to node B) by marking the second edge entry (from node B to node A) as "hidden" (e.g., using metadata and / or a flag of the edge entry). Marking unwanted edges as "hidden" allows the operating system to maintain graph data. For example, in order to delete node B from a graph where a unidirectional relationship from node A to node B exists, all references to node B should also be deleted. The operating system can use the hidden edge entry in node B's gnode to identify the unidirectional relationship from node A to node B, and remove the edge entry identifying node B from node A's gnode.

[0029] According to various embodiments, a GOFS partition includes dedicated space for each of the following items: a superblock, graph metadata, a block bitmap, a gnode bitmap, a gnode table, and data blocks. The block bitmap indicates which data blocks in the partition are occupied. The gnode table includes multiple slots for gnodes, and the gnode bitmap indicates which of those slots are occupied. In addition, the superblock identifies the root gnode and, according to various embodiments, includes the name of the root gnode. The root gnode of the GOFS identified in the superblock may change, which effectively changes the mount point of the GOFS. Since any absolute path to a node within the graph represented by the GOFS is interpreted based on the root gnode identified in the superblock, changing the root gnode of the GOFS changes how absolute paths are interpreted.

[0030] GOFS is implemented in the kernel space of a computing system. Thus, GOFS commands (e.g., originating from an application in the user space of the computing system) are transmitted to the operating system for implementation. GOFS commands can be submitted to the operating system from the user space via an application programming interface (API), a graphical user interface, or via a command line interface. According to various embodiments, the file system command is received by a file system interface of the operating system. The file system interface determines whether the command is for a hierarchical file system managed by a virtual file system switch (VFS) or for a GOFS in one or more GOFSs maintained by the computing system. If the command is for a hierarchical file system, then the command is transmitted to the VFS for processing. However, if the command is for GOFS, then the file system interface causes the file system command to be executed using a GOFS partition without intervention by the VFS. Because it is implemented in kernel space, GOFS management and implementation of submitted GOFS commands do not require intervention by any software running in user space.

[0031] According to various embodiments, the gnode data structure and / or the edge entry data structure include one or more "in-structure" metadata values ​​for characteristics of the represented node or relationship. In addition, according to various embodiments, the GOFS partition includes dedicated space for node and / or relationship metadata. This metadata space can be used to store "out-of-structure" metadata values, such as key-value pairs, which expands the amount of space available for graph metadata beyond the amount that can actually be stored in gnodes and edge entries. Metadata values ​​in the dedicated metadata space for the graph can be accessed using an associated gnode identifier or relationship identifier. In addition, the metadata space can be used to store metadata for superblocks, which are metadata values ​​for the GOFS or graph itself, rather than metadata values ​​for individual graph components.

[0032] Search operations can utilize metadata in gnodes, edge entries, and / or dedicated metadata spaces to efficiently identify search results from a graph without accessing the contents of nodes to identify search results. Search operations can include search criteria involving metadata values ​​in the structure of nodes and relationships as well as graph pattern matching and metadata values ​​outside the structure. Accessing metadata values ​​in the structure of a particular search operation can be performed using an index or from within the graph component data structure itself. Sometimes, using an index to access metadata feature values ​​in the structure is more efficient than accessing metadata feature values ​​in the structure within the graph component data structure. When the search criteria of a search operation involves metadata values ​​outside the structure, generating the search operation results can be based at least in part on (e.g., using a graph component identifier) ​​accessing a dedicated metadata storage device 320 to retrieve metadata values ​​outside the structure to perform. When metadata values ​​outside the structure are indexed, access to metadata values ​​outside the structure can be performed using an index.

[0033] Compared to a strictly hierarchical file system, using GOFS to store data allows for more flexibility in classifying data and identifying subtle relationships between data, for example, given that nodes in the represented graph may be related to any number of other nodes, and graph components may be associated with any type of metadata. The increased flexibility allows applications with a variety of files, with a variety of relationships (such as software packages, binary dependencies, system configurations, machine learning or artificial intelligence data, etc.) to be accurately represented by the operating system and accessed efficiently and effectively without forcing non-hierarchical data into a hierarchical data structure.

[0034] As a result, GOFS provides unparalleled performance for maintaining and processing complex data, such as data used for artificial intelligence, social networking, software packaging, mapping / geographic applications, 3D rendering, video games, web design, cloud applications, etc. For example, implementing graph data structures using data management software is not always portable to cloud infrastructures because the operating system of cloud infrastructures is usually not under the control of the user. Specifically, the data management software used may not be compatible with the operating system implemented on the cloud infrastructure. Implementing graph data structures at the operating system level ensures that all users can access graph features, including after porting graph data structures in GOFS to cloud infrastructures that are compatible with GOFS.

[0035] Furthermore, the GOFS techniques described herein allow for backward compatibility with the use of strictly hierarchical file systems, as the graph data structure can be configured to represent strictly hierarchical data, i.e., by creating only one relationship (e.g., a "contains" / "is_contained_by" relationship) between nodes in the file system graph. Thus, the techniques described herein add strictly hierarchical file system capabilities, providing users with much greater flexibility to represent hierarchical and non-hierarchical data.

[0036] GOFS further provides the flexibility to scale massively and supports massive data storage. For example, any number of GOFS can be connected and mounted within a computing device or a cluster of computing devices (where a "computing system" as used herein can be a single computing device or a cluster of computing devices), with the only limiting factor being the hardware. In addition, because GOFS is implemented by the operating system, software in user space does not need to record or maintain the graph-based data characteristics of the file system data. A user can import GOFS data created in one system into a second system that supports GOFS, and due to the file system-level encoding of the graph data, the ported data will maintain all graph-based relationships and metadata.

[0037] GOFS also provides ultra-high speeds for, for example, embedded applications with limited system resources. Specifically, because GOFS encodes metadata for nodes and relationships at the file system level, applications can perform file system operations without accessing additional information sources (such as software-maintained databases). Therefore, in addition to the flexibility and extensibility of GOFS, GOFS also provides computational improvements because file system operations do not need to involve software in user space, which is inherently less efficient than software running in kernel space.

[0038] 2. Operating system implementation of graph-organized file systems

[0039] GOFS is implemented in the kernel space of the computing system. Thus, GOFS commands (eg, originating from an application in the user space of the computing system) are transmitted to the operating system for implementation. Figure 2A An example computing system 200A is depicted that runs an application 210 in a user space of the computing system. In the system 200A, the application 210 interacts with a particular one of the file systems 230A-230N using a Portable Operating System Interface (POSIX) file system command via a virtual file system switch (VFS) 220 implemented in the kernel space of the system 200A. The file systems 230A-230N are kernel software that can implement any type of file system, such as NTFS, XFS, ext3fs, ext4fs, Fat32, ZFS, btrfs, ACFS, UFS, Minix, Ceph, etc.

[0040] VFS 220 is a software layer that enables a particular file system to implement POSIX file system commands issued by application 210 for a hierarchically organized file system by converting POSIX commands into instructions specific to the target hierarchically organized file system. Since VFS 220 abstracts the details of how a particular file system implements POSIX commands, application 210 can issue any type of POSIX command (such as open, read, write, or close) without modification for any type of file system. The target file system implements the received command on the identified files / directories, and the file system software automatically manages the details of how the files are stored (e.g., in cache data 240 and persistent storage 250).

[0041] VFS has been developed for decades and has excellent performance. However, VFS is closely related to hierarchically organized file systems (which store data in a strict hierarchical tree structure). Therefore, according to various embodiments, file system commands including GOFS commands such as Figure 2B Specifically, Figure 2B An example computing system 200B is depicted that implements a file system command interface 260 that routes file system commands (such as hierarchically organized file system commands or GOFS commands described in further detail below) to VFS 220 (in the case of hierarchically organized file system commands) or to a GOFS in one or more GOFSs implemented by system 200B (in the case of GOFS commands), such as GOFS 270. GOFS 270 is example kernel software that implements a particular GOFS according to the techniques described herein.

[0042] According to various embodiments, GOFS 270 uses much of the same cache (e.g., in cache data 240) and services utilized by file systems 230A-230N. For example, to improve latency of GOFS-based I / O read and write operations to persistent storage 250, GOFS 270 maintains and / or utilizes one or more caches, such as a page cache 242, a gnode cache 244 (where a gnode cache is similar in function and / or form to an inode cache), and / or a graph cache 246, which may be built into the memory of one or more implementing computing devices. According to various embodiments, graph cache 246 caches edge entry information being used by the operating system. Page cache 242 and gnode cache 244 may also be used by VFS 220 as a page cache and an inode cache, respectively. In addition, graph cache 246 may facilitate caching dentries, i.e., data structures representing directory information in a directory-based file system, and thus may be used by VFS 220 as a directory entry cache.

[0043] 3. Multi-device implementation of graph-organized file systems

[0044] Multiple computing devices may store data for the same graph, e.g., as part of a cloud implementation of GOFS. For example, in a distributed multi-device implementation, each device maintains a GOFS partition, as described in detail below, that stores a portion of the graph data. Each device may store a different portion of the graph, and / or may store at least some of the same graph data as one or more other devices. Data identifying the specific device storing the root node and which gnode to mount may be stored in superblock metadata or in an external database, among other things. As another example, in a multi-device implementation, multiple computing devices access the same graph data stored on a persistent storage device accessible by all of the multiple computing devices. In a multi-device GOFS implementation, the devices may coordinate using one or more software agents.

[0045] 4.GOFS Data Structure

[0046] 4.1GOFS Partition

[0047] According to various embodiments, system 200B stores data of GOFS 270 in a GOFS partition in a persistent storage device, such as persistent storage device 250 . Figure 3An example GOFS partition 300 is depicted, which includes a superblock 310, a dedicated metadata storage 320, a block bitmap 330, a gnode bitmap 340, a gnode table 350, and data blocks 360. The metadata storage 320 stores metadata for the superblock 310, gnodes, and / or relationships, as described in further detail below. The gnode table 350 includes a plurality of slots for storing gnode data structures, and the gnode bitmap 340 indicates which slots in the gnode table 350 are occupied. The block bitmap 330 indicates which data blocks (allocated for storing content data and edge entry data structures of the gnode, etc.) in the data blocks 360 are occupied.

[0048] The superblock 310 of the partition 300 is similar to a Unix superblock and contains summary information about the GOFS. Specifically, according to various embodiments, the superblock stores the size of the partition 300, an identifier of the root gnode of the GOFS 270, the name of the root gnode, the name of the partition 300, a modification timestamp of the partition 300, etc. As described in further detail below, the root node of the GOFS may change. Thus, according to various embodiments, the root gnode information maintained in the superblock 310 includes a gnode identifier, wherein the gnode of the root node is stored in the gnode table 350 along with other gnodes of the partition.

[0049] 4.2 Dedicated metadata storage

[0050] According to various embodiments, GOFS 270 provides one or more mechanisms for storing metadata values ​​that are characteristic of graph components, i.e., metadata values ​​that are distinct from any content associated with the graph components. Associating graph components with metadata values ​​allows users of GOFS 270 to encode various meanings into graph components. Associating graph components with metadata values ​​allows various low-cost lookup functions and read entry functions, and increases the potential power of search operations performed on GOFS data, given that GOFS 270 can access stored metadata values ​​without requiring the system to access node content data.

[0051] The characteristics of the graph component associated with the graph component metadata value can be anything selected by the user, such as a weight, type, genus, classification, or any other attribute of the graph component. According to various embodiments, the metadata values ​​are stored as key-value pairs, with a characteristic identifier as the "key" of a given key-value pair and the associated metadata value as the "value" of the key-value pair. Metadata values ​​for graph component characteristics can be stored in a dedicated metadata storage device 320 ("out-of-structure" values) or in a graph component data structure ("in-structure" values, as described in further detail below). Metadata values ​​stored in a dedicated metadata storage device 320 are called "out-of-structure" values ​​because these values ​​are not stored in the data structure representing the graph component, but are instead stored in a dedicated metadata storage device of a GOFS partition.

[0052] According to various embodiments, the extra-structural metadata value is accessed based on an identifier of the graph component to which the metadata value belongs, or based on a metadata identifier stored in a data structure of the graph component, etc. For example, the extra-structural metadata value of a particular relationship is accessed using a relationship identifier of the particular relationship (which is associated with two edge entries representing the relationship, as described in further detail below), and the extra-structural metadata value of a particular node is accessed using a gnode identifier of a particular node.

[0053] According to various embodiments, GOFS270 establishes a node metadata hash table and a relationship metadata hash table in a dedicated metadata storage device 320, and identifies a bucket of the hash table for storing a specific metadata value based on an identifier of a graph component associated with the metadata value. Each hash bucket includes, for example, in a linked list of hash table entries, the extra-structural metadata values ​​of all graph components whose identifiers are hashed to the bucket. To illustrate, when a graph component identifier is hashed to a particular bucket, an entry with the extra-structural metadata value of the graph component and the component identifier is added to any existing list of entries in the bucket. To retrieve the extra-structural metadata value of a graph component, the graph component identifier is hashed to identify a bucket for the graph component, and the data structure in the bucket is traversed to identify an entry including the graph component identifier.

[0054] According to various embodiments, metadata values ​​for a relationship represented by two edges are stored. Metadata values ​​for a relationship associated with a single edge of the relationship can be identified in any manner, for example, by associating the metadata value with a gnode identifier that identifies a source node of the associated edge, by associating the metadata value with an edge identifier that is unique to the associated edge, by creating a relationship property that is intrinsically associated with a particular edge of the relationship, etc.

[0055] In addition, the metadata space can be used to store metadata for superblocks, which are metadata values ​​of GOFS270 or the graph itself, rather than metadata values ​​of individual graph components. For example, GOFS270 stores a key-value pair of a superblock associated with a reserved identifier that identifies a superblock metadata value, where the reserved identifier can be used to retrieve the superblock metadata value. Such metadata values ​​can include values ​​for the root gnode name, the root gnode identifier, additional devices, additional volume managers, etc., examples of which include: nodeBitmapDevice= / dev / sdb1; BlockMapDevice= / dev / sdb2; FilesystemID=3ef81ac24e; Journal=Yes; FlushOnWrite=Yes; MetaDataIndex=RBT; and SpareVolumeData= / dev / volumes / 4de8fb213ab6.

[0056] 4.3GNODE data structure

[0057] GOFS 270 maintains a gnode table 350 in GOFS partition 300 that stores a gnode data structure ("gnode") for each node in the graph represented by GOFS 270. The nodes represented by gnodes may be associated in various ways with no data or any type of data, such as text data, spreadsheet data, utility data, executable data, library data, image data, video data, etc., and each node has one or more relationships with one or more other nodes.

[0058] Figure 4 An example gnode 400 is depicted, which is identified by a gnode identifier (e.g., corresponding to the slot in the gnode table 350 that the gnode occupies) and contains information defining the represented node. The example gnode 400 includes a plurality of node fields 402, a content field 410 for node content data (if any), and an edge field 420 for relationship data. In the example gnode 400, the content field 410 includes a pointer to a data block in the data block 360 storing the content data, and the edge field 420 stores an edge entry data structure ("edge entry") representing a node relationship and / or a pointer to a data block in the data block 360 storing the edge entry, as described in further detail below. The example node fields 402 store metadata values ​​in the structure for each of one or more specific node characteristics, one or more node flags, mode information, owner information, a group identifier, a timestamp of the node, a size of the content data of the node, a count of edges originating from the node, and the like.

[0059] The mode field of gnode 400 includes permission information for the node. The traditional Unix inode permission scheme is based on nine bits, including one bit for each of the read, write, and execute permissions for each category in user, group, and other. These bits cause the system to behave differently depending on whether the inode represents a file or a directory. According to various embodiments, this scheme is implemented for a gnode (i.e., in the mode field of the gnode), as depicted in Table 1 below:

[0060]

[0061] Table 1

[0062] For GOFS 270, the permission information in gnode 400 may apply to content data, edge data, or gnode metadata. The 9-bit permission scheme in Table 1 utilizes the same permission bits for content data permissions, edge data permissions, and gnode metadata permissions.

[0063] According to various embodiments, Table 2 below depicts another example gnode permission scheme with 24 bits (instead of the 9 bits depicted above):

[0064]

[0065] Table 2

[0066] The 24-bit permission scheme of Table 2 provides a set of bits for each of the content data, edge data, and gnode metadata, which allows for detailed control and access restrictions for each type of data. According to various embodiments, the gnode metadata bits of the permission information indicate read or write permissions to metadata values ​​in / out of the structure and / or to information in the node field 402. The first six bits control the reading and writing of gnode metadata, the next nine bits applied to edge data work similarly to the Unix standard permission scheme for directories, and the last nine bits applied to content data work similarly to the Unix standard permission scheme for files.

[0067] According to various embodiments, gnode 400 also includes a flag field, for example, a 64-bit field, the bits of which may be used as one or more flags for the represented node. According to various embodiments, the flag field of gnode 400 includes one or more "visited" flags. The one or more visited flags may be used by one or more search algorithms on the graph data to track which nodes each search algorithm has visited. In the case of a 64-bit flag field, up to 64 concurrent search operations running against the graph data may utilize corresponding flags in the visited flags. Mutexes or semaphores may be used to prevent deadlocks between applications accessing the flag field.

[0068] According to an embodiment, the flags field includes "system" information, which includes a number of bits corresponding to the following gnode type attributes: standard, pipe, socket, block device, and / or character device. The system information can also be implemented as a number or other type of value indicating the gnode type attribute, rather than a set of bits. In addition, the system information can be stored in a different field other than the flags field in the node field 402.

[0069] As indicated above, the example content field 410 depicts a pointer to a data block storing the content data of the represented node. However, some applications (such as neural networks) may require nodes with only a small amount of content data (if any). For example, a GOFS file system representing neural network data represents the required data in gnode metadata, relationships between nodes, edge weight metadata (e.g., in the metadata value in the structure), and a small amount of node content data. Therefore, according to various embodiments, the content field 410 can directly store the content of the represented node, rather than storing a pointer to the data block 360 storing the content of the represented node. In such an embodiment, the gnode 400 includes a content interpretation flag (e.g., in the flag field or in a dedicated location in the content field 410) that indicates whether the content field 410 should be interpreted as content data or pointer data. According to various embodiments, additional fields can be added to the gnode 400 to directly store content data, wherein the content field 410 is interpreted as one or more pointers to additional content data.

[0070] 4.4 Edge Entry Data Structure

[0071] GOFS's relationships are not limited to the directory-based relationships of a hierarchical file system. According to various embodiments, the number of relationships that can be associated with a given node is unlimited, and each relationship can represent any type of relationship between nodes. For illustration, Figure 5A depicts an example diagram represented by a GOFS partition 300, and Figure 5B Another example diagram represented by a GOFS partition 300 is depicted. Specifically, Figure 5A Depicted is a graph 500 having nodes V0-V4 represented by gnodes as described above, and relationships 512-526 between the nodes. Figure 5A Each node V0-V4 shown in has a name with an associated extension that identifies the type of content data that the node stores or may store, and each node has one or more relationships with one or more other nodes.

[0072] According to various embodiments, each relationship in the graph represented by GOFS partition 300 has two edges. Each edge is directed, having a source (or subject) node and a destination (or object) node. An edge whose source is a particular node is referred to herein as an outgoing edge of the source node, and an edge that identifies a particular node as the destination of the edge is referred to herein as an incoming edge of the destination node. For example, relationship 512 is represented by a first edge V0→V1, where V0 is the source node and V1 is the destination node, and a second edge V1→V0, where V1 is the source node and V0 is the destination node. Therefore, V0→V1 is an outgoing edge of V0, and V1→V0 is an outgoing edge of V1.

[0073] Each edge of the graph is represented by an edge entry data structure ("edge entry") included in or identified by an edge field 420 in the gnode representing the source node of the edge. In addition, each edge entry includes a relationship identifier for the relationship represented by the edge, a gnode identifier for the destination node of the edge, and a name for the destination node of the edge. According to various embodiments, each edge entry also includes a field for metadata values ​​for the represented edge or the relationship to which the represented edge belongs. These metadata values ​​are "in-structure" metadata values ​​because they are stored in the edge entry itself, rather than in a dedicated metadata storage device 320. According to various embodiments, the edge entry includes a reference to an out-of-structure metadata value for the represented edge within the dedicated metadata storage device 320.

[0074] According to various embodiments, each edge entry also includes a flag field having one or more flags for the represented edge. The flags of the edge represented by each edge entry include one or more of the following: a traversable flag, a hidden flag (such as an operating system-specific hidden flag and / or a user-initiated hidden flag), or an access flag, etc. The traversable flag can be used to indicate whether the represented edge can be used to access the destination node. A user can use a user-initiated hidden flag to "hide" a specific edge (for example, in connection with a specific search operation), where the user can choose to "unhide" the edge. The visited flag can be used to identify whether the edge has been "visited" by a search operation, for example. According to various embodiments, each edge is associated with multiple visited flags, which can be used by corresponding multiple concurrent search operations, similar to the visited flag of the gnode described above. The operating system-specific hidden flag will be described in further detail below.

[0075] Figure 6Depicted is an example gnode table 600, which is an example of a gnode table 350 for a partition 300. Each gnode in table 600 (a) represents one of nodes V0-V4 of graph 500, and (b) includes a node field 402, a content field 410, and an edge field 420 identifying an edge entry for an outgoing edge of the represented node. In table 600, all contents in the gnode except the edge field are abbreviated to better illustrate the edge entry. In addition, the edge entry of a gnode is depicted as being contained in the gnode. However, the edge entry can be stored in a data block 360, and a reference to a related data block can be stored in an edge field 420.

[0076] As depicted in gnode table 600, each edge entry contains a relationship identifier that is the same for both edges of the relationship. According to various embodiments, each edge may be assigned a unique identifier, for example, by concatenating an edge-specific value to the relationship identifier, such as assigning 512_A and 512_B for the edges of relationship 512. Using the relationship identifiers for both edge entries of a relationship allows the operating system to quickly identify the two edge entries for a given relationship. Thus, the operating system can perform relationship-based operations on both edge entries of a relationship, or can easily identify edge entries of a relationship that should be removed.

[0077] According to various embodiments, each edge entry includes a metadata field, such as a 64-bit weight field, that stores one or more in-structure metadata values. In addition, the metadata field may include a pointer to the metadata value of the edge in a dedicated metadata storage device 320. Embodiments may encode the in-structure metadata value of the edge in any manner, such as a key-value pair that identifies the characteristics of the represented edge or relationship. The key-value pairs may be set and interpreted by various applications that utilize GOFS data, and may allow for powerful and efficient searches of the graph data.

[0078] The edge metadata values ​​in the structure can be used to store different metadata values ​​for the edges of a given relationship, such as different weights or types of the edges. As shown in gnode table 600, the edges of relationship 512 have the same in-structure weight metadata value ("111"), but the edges of relationship 514 have different weights (V1→V2 is "7981", and V2→V1 is "12"). As another example, a specific relationship between node A and node B is represented by a first edge entry A→B and a second edge entry B→A. In this example, the nodes represent people, and the relationship is a parent relationship, where node A represents the parent and node B represents the child. Therefore, the two edges of the relationship have different types, that is, the type of A→B is "parent of...", and the type of B→A is "child of...". To represent different edge types, the relationship metadata may include properties "source_parent_of" and "source_offspring_of", where the metadata values ​​stored in the dedicated metadata storage 320 indicate "source_parent_of=A_ID" and "source_offspring_of=B_ID" (where "A_ID" is the gnode identifier of node A, and "B_ID" is the gnode identifier of node B). In addition, the edge entry A→B and the edge entry B→A may each be associated with a "type" property in the structure, for example, where the edge entry A→B is associated with a "type" metadata value "parent of...", and the edge entry B→A is associated with a "type" metadata value "child of...".

[0079] As indicated above, an edge entry stores the “name” of the destination map node of the represented edge. According to various embodiments, different edge entries may identify different names for the same graph node.

[0080] 4.5 One-way relationships

[0081] Although a relationship is represented by two edges, it can be unidirectional. To illustrate, Figure 5B A graph 530 is depicted that is similar to graph 500 , except for the addition of a node V5 and a unidirectional relationship 532 originating from V5 (the source node) and terminating at V1 (the destination node). Figure 7A-7B Example gnode table 700 of shows gnode and edge entries representing graph 530. As shown in example gnode table 700, unidirectional relationship 532 (which has a source node and a destination node) is represented by two edge entries, one at source gnode V5 and the other at destination gnode V1.

[0082] The edge entries of the gnodes in table 700 include a flag field that depicts an operating system-specific hidden flag for each edge entry. The operating system-specific hidden flag can be used to indicate whether the represented edge is hidden by the operating system, such as the edge of a unidirectional relationship that is opposite to the direction of the relationship. Returning to the discussion of table 700, the operating system-specific hidden flags of all edge entries in table 700 are set to "FALSE", except that the edge entry of relationship 532 recorded at the gnode of V1 has its hidden flag set to "TRUE". This flag indicates that relationship 532 is unidirectional, originating from V5 and terminating at V1.

[0083] Marking unneeded edges as "hidden" allows the operating system to maintain graph data. For example, to delete V1 from the graph, the gnode for V1 and all edge entries terminating at V1 should be deleted from table 700. The operating system can use the edge entries for V1's gnode to identify all gnodes that have edge entries identifying V1. Therefore, since the edge of relationship 532 originating from V1 is hidden rather than non-existent, the operating system can use the "hidden" edge entries to determine that V5 has an edge entry with V1 as the destination that should be deleted.

[0084] The behavior of edges hidden by the operating system may differ from the behavior of edges hidden by users, such as a user without at least a certain level of privilege (e.g., "root" privileges) may not be able to "unhide" edges hidden by the operating system except in certain circumstances. In the case of an operating system-specific hide flag for hiding the opposite edge of a unidirectional relationship, a user may clear the operating system-specific hide flag for that edge by converting the unidirectional relationship into a bidirectional relationship.

[0085] The ability to create unidirectional relationships within GOFS is useful in a variety of contexts, such as in the context of programming containers or virtual machine (VM) instances. A programming container encapsulates a computer program application within a separate, relatively isolated runtime environment that uses the operating system kernel of a host computer. A VM instance also encapsulates a computer program application within a separate, isolated runtime environment and includes an entire operating system run by a hypervisor on top of the operating system kernel of the host computer. A container or VM instance can bundle an application and its dependencies, libraries, and configuration files into a single package that is portable between computing devices with different environments.

[0086] When a computing device's hypervisor hosts multiple virtualization instances containing containers and / or virtual machines, the nodes represented by these virtualization instances can be considered part of the same graph maintained for the computing device. A unidirectional relationship connecting each virtualization instance's specific "root" node to the rest of the graph can prevent applications within the virtualization instance from escaping from the portion of the graph representing the virtualization instance, while the hypervisor can still access data in the mounted virtualization instance.

[0087] 4.6 Disconnected Nodes

[0088] All nodes in a graph should be accessible from the root node of the graph. To do this, a node is created in the GOFS, along with one or more relationships that directly or indirectly connect the node to the root node of the GOFS. However, deleting a node or relationship from the graph may potentially disconnect one or more nodes from the root node. To illustrate in the context of graph 530, deleting the relationship between V5 and V1, or deleting V1 from the graph, would make V5 a disconnected node with no relationship connecting the node to the root node V0.

[0089] Thus, according to various embodiments, in association with performing any delete operation that deletes a relationship or node from a graph, the operating system checks to determine whether the delete operation will disconnect any nodes from the root node (such a delete operation is referred to as a "disconnected" delete operation). If the delete would result in one or more disconnected nodes, the operating system performs one or more of the following actions: deleting the disconnected nodes; or adding a relationship between the disconnected nodes and specific other nodes in the graph. The action taken in this context may be an action indicated by the user, for example, in configuration information, or as a result of asking the user how to handle the disconnected nodes in response to determining that the requested delete operation is a disconnected delete operation. The specific other node that is automatically associated with the disconnected node may be a default node, or may be identified by the user, for example, in configuration information, or as a result of asking the user which node should be associated with the disconnected node. If the specific other node does not yet exist when the disconnected delete operation occurs, the specific other node may be generated at a default location or at a location indicated by the user.

[0090] 4.7 Changing the root node

[0091] Any node in GOFS 270 can be the root node of the file system data identified in superblock 310. In addition, the root node identified in superblock 310 can change to any node within the graph. According to various embodiments, when the identifier of the root gnode changes, the name of the root gnode maintained for superblock 310 (e.g., in the metadata of superblock 310) will also change. To illustrate in the example of graph 500, graph node 502 ("V4") is the root node of the graph, which is reflected in superblock 310. Therefore, the absolute path of each of nodes V0-V4 starts from root node 502, as shown below:

[0092] V0: ^V4 / V0

[0093] V1: ^V4 / V1

[0094] V2: ^V4 / V3 / V2 or ^V4 / V0 / V2 or ^V4 / V1 / V2

[0095] V3: ^V4 / V3

[0096] V4: ^V4

[0097] Note that in these examples, the root node is identified by a name (i.e., "V4") and a "^" character to identify it as the root node of the graph. However, the root node can be represented in any manner, such as using " / " to represent the root node, thereby generating an absolute path beginning with " / " to identify it as an absolute path, for example, " / V0" as an absolute path name to identify V0. In addition, the shortest path name for each node is provided above. However, one or more alternative path names can be used to identify nodes other than the shortest path, if such alternative paths exist in the graph. For example, an alternative absolute path name for V0 is "^V4 / V3 / V2 / V0", which is one of many valid paths from ^V4 to V0 through graph 500.

[0098] The user can change the root node of the graph from V4 to V0, such as Figure 5B Thus, the absolute path of each node in nodes V0-V4 starts from the new root node 504, as shown below:

[0099] V0: ^V0

[0100] V1: ^V0 / V1

[0101] V2: ^V0 / V2

[0102] V3: ^V0 / V3

[0103] V4: ^V0 / V4

[0104] Path names identifying nodes of a graph can be relative to the current ("working") node, rather than absolute paths. For example, in the context of graph 500, although V3 is the working node, a user traverses directly from V3 to V1 using a relative path from V3 to V1 ("cd V2 / V1") or using an absolute path identifying V1 ("cd ^ V4 / V1").

[0105] According to various embodiments, a command such as chrootsys may cause the root gnode of a system to be changed, as described in detail above.

[0106] 4.8 Metadata Index

[0107] In conjunction with graph pattern-based queries on graph data, metadata values ​​in the structure can be accessed very quickly, such as graph pattern queries that are configured to perform searches such as: "Find all nodes related to Joe Smith's medical records within three hops" or "Find all texture type nodes that are linked to the 3d design project represented by a given node." For example, a particular search operation may have criteria based on a graph pattern and also based on metadata values ​​in a particular structure (such as finding all nodes representing mothers who are less than 25 years old and have at least one child who is over 7 years old, where age is a node property associated with a metadata value in the structure). When traversing the graph to identify nodes that satisfy the graph pattern, it is typically very efficient to determine whether the graph component also satisfies the search criteria based on metadata values ​​in the structure because these values ​​are stored in the graph component structure itself.

[0108] However, for search operations that do not involve graph patterns but instead have search criteria based on in-structure or out-of-structure metadata values ​​(such as finding all nodes representing people over the age of 85), identifying graph data that meets the search criteria typically requires traversing the dedicated metadata storage device 320, or traversing the graph component data structure to access the in-structure metadata value. To alleviate the need to traverse the graph component data structure to identify graph components with specific in-structure metadata values, the in-structure metadata values ​​can be loaded into the graph cache 246 and / or a metadata cache maintained by GOFS270 (e.g., within cache data 240 and / or within a GOFS partition). Any changes made to the in-structure metadata value will invalidate the cached copy of the changed value.

[0109] Thus, according to various embodiments, dedicated metadata storage 320 and / or data block 360 stores one or more indexes (such as B-tree indexes) regarding one or more graph component metadata properties corresponding to one or more out-of-structure and / or in-structure metadata values. The one or more indexes can be used to speed up queries on the graph by quickly identifying which graph components are associated with specific metadata values.

[0110] For example, a graph component (node ​​or relationship) of GOFS 270 is associated with a "type" property, which is expected to be used as a search criterion for a search operation on the file system. Therefore, the operating system creates an index of the values ​​of the "type" property in partition 300. The index includes graph component identifiers of various components having different index values ​​of the "type" property. When a search operation is performed using criteria involving the "type" property, the search operation will be automatically performed based on the index to quickly identify graph components having a specific value associated with the "type" property.

[0111] 5.GOFS User Interface

[0112] According to various embodiments, GOFS270 supports commands for search operations, file system management, permission management, navigation operations, node handling operations, edge handling operations, metadata handling operations, etc. via a user interface (such as a graphical user interface, a command line interface, an API, etc.).

[0113] 5.1 Search Commands

[0114] GOFS 270 and / or application 210 are configured to perform search operations on the graph represented by GOFS partition 300. The search operations may be based on any type of search criteria, including any of: graph patterns, in-structure metadata values, and out-of-structure metadata values.

[0115] According to various embodiments, such a search operation is based at least in part on search criteria that include specific node properties associated with metadata values ​​in the structure and specific edge properties associated with metadata values ​​in the structure. For example, GOFS270 receives a search operation command to find all nodes representing mothers who are less than 25 years old and have at least one child over 7 years old, where "age" is a node property associated with a metadata value in the structure, "gender" is a node property associated with a metadata value outside the structure, and "type" is a relationship property associated with a metadata value in the structure.

[0116] Performing a search operation includes generating a search operation result based at least in part on accessing a structure metadata value of a specific node property and accessing a structure metadata value of a specific edge property. If there is an index about a specific node property or an index about a specific edge property, then the index can be used to access the structure metadata value of the indexed property. In addition, the structure metadata property value can be accessed within the graph component data structure itself. Sometimes, using an index to access the structure metadata property value is more efficient than accessing the structure metadata property value within the graph component data structure. The determined search operation result is returned to the requesting entity.

[0117] When the search criteria of the search operation involves an extra-structural metadata value, generating a search operation result can be performed based at least in part on accessing the dedicated metadata storage device 320 to retrieve the extra-structural metadata value. As described in detail above, the extra-structural metadata value can be indexed and the index can be used to access the extra-structural metadata value.

[0118] To illustrate, the above example search operation is performed by an operating system in which an index is maintained regarding metadata property values ​​in a structure regarding the ages of people represented by nodes. Thus, to perform the search operation, the operating system uses the index regarding the age node property to identify an intermediate result for a query indicating all nodes associated with age metadata values ​​less than 25.

[0119] The operating system uses the gnode identifiers in the intermediate result to determine which nodes are associated with the "female" gender metadata value in the dedicated metadata storage device 320. For example, when a hash table for extra-structural node metadata values ​​is maintained in the dedicated metadata storage device 320, the operating system uses the gnode identifiers in the intermediate result to identify the bucket in the hash table where each gnode data is stored. To identify the extra-structural metadata value for a particular gnode, the operating system traverses the list of gnode entries in the corresponding bucket to identify the gnode entry for the particular gnode. Once the gnode entry for the particular gnode is identified, the operating system determines whether the gender metadata attribute value in the hash table entry is "female" and, if so, adds the gnode identifier to the second intermediate result of the search operation.

[0120] Once all gnodes with gender attribute value of "female" and age below 25 are identified in the second intermediate result, the operating system performs pattern matching on the graph data to identify which gnodes in the second intermediate result have a parent type relationship with gnodes representing children above 7 years old. The in-structure metadata value search criteria is analyzed using the in-structure metadata attribute values ​​for the relationship "type" attribute and the node "age" attribute retrieved from the graph component data structure itself.

[0121] 5.1.1 Search Command

[0122] GOFS 270 supports search operation commands, such as a find command, which causes the operating system to locate nodes in the represented graph based on provided search criteria. According to various embodiments, the find command automatically uses any applicable index maintained within partition 300 for the search operation, and if applicable, utilizes a cache in cache data 240 (such as graph cache 246) or free space within partition 300 to store data for the search operation in order to efficiently perform the operation.

[0123] According to various embodiments, the following are example properties and usage examples of a find command. Specifically, GOFS 270 implements a find command for a command line interface that takes a search expression as a parameter to identify one or more nodes and / or one or more relationships within GOFS. According to various embodiments, the find command has the following pattern (wherein, in the following description, square brackets ([]) indicate optional elements, angle brackets (<>) indicate required elements, and round brackets indicate grouping):

[0124] find search_pattern [options]

[0125] According to various embodiments, the find command supports the following:

[0126] Operators

[0127]

[0128]

[0129] Notation of edges / relationships:

[0130] Edges can be represented by paths, such as / v0 / v1, which represents an edge from v0 to v1. However, files can also be represented in this way. Therefore, according to various embodiments, the identification of edges is performed using special operators or edge identifiers, such as / v0->v1, v0>v1, or / v0:[edgeid], etc.

[0131] Find options for graph node searches

[0132] (These lookup options may work with the help of graph cache 246 and metadata store 320.)

[0133]

[0134]

[0135]

[0136] Find options for edge / relationship searches

[0137] (It may work with the help of both the graph cache 246 and the metadata storage 320, or only with the help of the metadata storage 320.)

[0138]

[0139]

[0140] The following example is Figure 5AAn example of a search run in Figure 500 where the weight metadata is as follows Figure 6 Indicated in the gnode table 600 of . According to various embodiments, the "visited" flag of each gnode will be required to perform the search to avoid visiting nodes that have already been visited. Note that the GraphQL variant used in the example adopts a format such as (f)-[r], which indicates that the target operation is for (node)-[relationship].

[0141] Example:

[0142]

[0143]

[0144]

[0145]

[0146]

[0147]

[0148] 5.1.2 Visited Flag

[0149] According to various embodiments, one or both of the gnode data structure and the edge data structure stores one or more "visited" flags that can be used during the execution of a search operation. For example, the gnode includes a corresponding bit array for the "visited" flag (referred to herein as "visited[]"). In association with the execution of a particular search operation that requires a graph pattern match, the operating system determines that visited[2] is not currently used for the search operation and reserves visited[2] for the particular search operation. When a particular node has been evaluated to determine whether the node satisfies the graph pattern for the particular search operation (i.e., the node is "visited"), the bit at visited[2] is set to a first value (e.g., '1'). During further traversal of the graph for the particular search operation, the value of visited[2] can be used to determine whether the node has been previously visited and avoid unnecessary revisiting of the node, thereby eliminating the work of repeatedly performing the search operation.

[0150] According to an embodiment, once a particular search operation is completed, the operating system automatically sets all bits at visited[2] of all gnode data structures to a second value (e.g., '0') and marks visited[2] as not currently being used for a search operation. Thus, visited[2] is available for use by subsequent search operations. The edge entry "visited" flag is used in a manner similar to the gnode "visited" flag, as described in the example above, to track which edges or relations have been "visited" for a given search operation.

[0151] 5.2 File system management commands

[0152] GOFS 270 supports file system management commands, including the following commands represented by commands of the command line interface (where an example of a gnode table is gnode table 350 ( Figure 3 ), and an example of metadata used as follows is a dedicated metadata space 320 ( Figure 3 ) and / or the metadata field in the structure in the node field 403 ( Figure 4 )):

[0153] fstat: Displays GOFS statistics and the number of gnodes in the graph, the number of edges in the graph, and the number of free slots in the gnode table.

[0154] dumpgnode: [debug] Dump all gnodes.

[0155] dumpslots: [debug] Dump the slots used by metadata in the gnode table.

[0156] dumpino: [debug] Dump gnode data in both gnode table and metadata.

[0157] dumpedges: [debug] Given a gnode, dump the edges in the metadata.

[0158] gnode: Displays a list of all gnode identifiers for the file system.

[0159] Permission management commands

[0160] GOFS270 supports permission management commands, including the following commands represented by the command line interface:

[0161] chperms / chmod: Change the gnode permissions [the rightmost 24 bits of the gnode:mode field].

[0162] · chino: Change gnode field permissions [bits 18-23 in the gnode:mode field].

[0163] chedge: Change gnode edge permissions [bits 9-17 in the gnode:mode field].

[0164] chdata: Change the gnode data permissions [bits 0-8 in the gnode:mode field].

[0165] chown: Change the gnode owner, gnode:uid field.

[0166] chgrp: Change the gnode group, gnode:gid field.

[0167] · access: Given a gnode, check whether the indicated access type is possible for the current user.

[0168] 5.3 Navigation Commands

[0169] GOFS270 supports navigation commands, including the following commands represented by the command line interface:

[0170] ls: Displays a list of traversable edges at the current node. According to various embodiments, edges can be represented in any manner, such as using special symbols and the name of the destination node. For illustration, in Figure 500 ( Figure 5A ), the user navigates to V1 and invokes the ls command. The following results are displayed, indicating the traversable edges originating from V1, where the special edge symbol is ->:

[0171] ->V0

[0172] ->V2

[0173] ->V4

[0174] lsedges: Displays a list of all edges (except OS_hidden edges) at the current node.

[0175] cd: Go to the node identified by the specified pathname.

[0176] pwd: Get the absolute path name of the current working node.

[0177] Graph: Displays all nodes in the file system, similar to the "tree" utility in Linux.

[0178] 5.4 Node Disposal Commands

[0179] GOFS 270 supports node handling commands, including the following commands represented by commands of the command line interface:

[0180] mknod / touch: Create a new node with a relationship to the current working node.

[0181] store: Add data to the current working node or target node.

[0182] stat: Provides information about the current working node or target node.

[0183] cat: dumps the content data of the current working node or target node.

[0184] • mv: Moves the identified node to a specified location identified by a specific destination node identifier by deleting all existing relationships involving the identified node and establishing a new relationship between the identified node and the specific destination node.

[0185] mvow: overwrite the destination node with the source node by removing all relationships involving the source node, creating new relationships between the source node and any nodes with which the destination node has relationships (optionally migrating any metadata from the old relationships to the corresponding new relationships), and deleting the destination node.

[0186] cp: Make a copy of the source node with all existing relationships and establish new relationships between the copy and the destination node.

[0187] cpow: overwrites the destination node with a copy of the source node by copying the source node (possibly with existing relationship information), establishing new relationships between the copy of the source node and any nodes with which the destination node has relationships (optionally applying any metadata from existing relationships to the corresponding new relationships), and deleting the destination node.

[0188] rm: Delete the target node and all its relationships.

[0189] rename: Renames the target node identified by the specified path (updates only the specified edge entries).

[0190] chroot: Change the root node to the current working node or target node. According to various embodiments, the chroot command is only valid in the current process and will not affect the entire system or other users and processes. This means that if a user issues a chroot, it will only affect the user's own process. Therefore, the chroot command can be applied in the context of a container. For example, a container application runs a chroot command when it is launched, after which the container and its child processes are constrained to run within the identified portion of the file system space.

[0191] chrootsys: causes the system's root gnode to be changed, as described in detail above.

[0192] isolate: Make a set of identified relationships originating from the current working node unidirectional by marking the edge entries of the identified relationships at the current working node as hidden (e.g., by setting a user-initiated hidden flag for each edge entry).

[0193] nodesetflags: Sets / unsets the identified flags bits of the identified node.

[0194] 5.5 Edge Disposal Commands

[0195] GOFS 270 supports edge handling commands, including the following commands represented by the command line interface:

[0196] mkrelat / link: Creates a relationship between a specified pair of nodes.

[0197] rmrelat / unlink: Delete the relationship between a specified pair of nodes. If the execution of this command causes the nodes to be disconnected, the disconnected nodes will be handled as described in this article.

[0198] edgesetflags: Sets / unsets the identified flags bits of the identified edge entry.

[0199] According to various embodiments, an edge is identified by identifying a source node and a destination node of the edge. Additionally, a relationship is identified by identifying two nodes that are related by the relationship.

[0200] 5.6 Metadata Disposition Commands

[0201] According to various embodiments, the out-of-structure metadata values ​​of the graph components are stored as key-value pairs in a dedicated metadata storage device 320, and / or the in-structure metadata values ​​are stored in the data structure of the graph component itself. GOFS 270 supports metadata handling commands, including the following commands represented by commands of the command line interface:

[0202] lsattr[superblock|node|relat]: Lists all key-value pairs assigned to a superblock, a specific gnode, or a relation.

[0203] ·setattr[superblock|node|relat]key=value: Set a key-value pair for a superblock, a specific gnode, or a relation.

[0204] getattr[superblock|node|relat]key: Given a key, retrieve a value from a superblock, a specific gnode, or a relation.

[0205] rmattr[superblock|node|relat]key: Given a key, remove a value from a superblock, a specific gnode, or a relation.

[0206] clnattr[superblock|node|relat]: Clears all key-value pairs assigned to a superblock, a specific gnode, or a relation.

[0207] searchattr[key operator value]: Simple search for a key and key-value pair in the metadata store. Will show possible node or relationship matches depending on user permissions, invisible flags, etc.

[0208] According to various embodiments, metadata handling commands are applied to out-of-structure metadata values ​​or in-structure metadata values ​​based on options of each command. According to various embodiments, separate metadata handling commands are provided to handle out-of-structure metadata values ​​and to handle in-structure metadata values.

[0209] In addition, according to various embodiments, various commands for editing metadata (e.g., the commands identified above) are associated with aliases for operating on superblocks, nodes, and relationships. For example, lsattr is associated with the aliases lsattrsuper, lsattrnode, and lsattrrelat, which operate on superblocks, nodes, and relationships, respectively.

[0210] 5.6.1 Using ".." in path names

[0211] A traditional directory entry list for an inode in a hierarchically organized file system typically includes a "." entry pointing to the inode itself and a ".." entry pointing to the parent directory of the inode. However, a graph does not have the directionality imposed by a hierarchically organized file system, which in many cases eliminates the idea of ​​a "parent" node. Therefore, in accordance with various embodiments, in GOFS 270, a gnode's edge entry list includes a "." entry pointing to the gnode itself, and omits the ".." entry.

[0212] According to various embodiments, a user may utilize ".." in a path name of a file system command, where the interpretation of ".." in the command is handled by the operating system, for example, at the file system command interface 260. The manner in which ".." is handled may be indicated by user configuration information, which may instruct the operating system to interpret ".." as a reference to a node that is the destination of an outgoing edge having a maximum or minimum value of a particular edge property (such as a weight), or as a reference to a penultimate path node (the penultimate path node is a node identified in a path name used to navigate to the current working node, the node identified in the path name immediately preceding the current working node, or in the absence of a path name with a penultimate node, a node that is a working node immediately preceding the current working node), etc.

[0213] For example, in Figure 5A In the context of Figure 500, a user uses the command "cd . / V1 / V2" to navigate from V0 (the current working node) to V2. In this case, the penultimate path node is V1 because it is the node identified in the path name used to navigate to V2, which node is identified immediately before V2 in the path name. After navigating to V2 using this command, the user issues the command "cd ..". When the user configures a penultimate path interpretation that requires "..", this command causes the operating system to navigate to V1.

[0214] As another example, a user navigates from V0 (the current working node) to V1 using the command "cd V1". In this case, there is no penultimate path node. Therefore, if after navigating to V1 using this command, the user issues the command "cd ..", the operating system interprets ".." as meaning the previous working node or V0. For example, the operating system maintains a current working node (similar to the "current working directory", cwd) for all running processes, which indicates the current location of each running process in the graph data. Therefore, if a process issues a command involving "..", such as "cd .." or "cd .. / .. / home", the operating system will use the current working node value maintained for the process and the data returned by the file system edge entry retrieved by the process to obtain the absolute location of the process.

[0215] 5.7 Feature Tags

[0216] According to various embodiments, GOFS270 provides a user interface that allows a user to define a set of graph component properties associated with a unique user-defined tag. The user can then apply the tag to a particular graph component, which causes GOFS270 to include all properties associated with the applied tag in the metadata of the graph component. According to various embodiments, after the user applies the tag to the graph component, GOFS270 requests the value of the tag property to be included in the metadata of the graph component. The user can indicate via the user interface whether a particular property metadata value should be stored in the structure or outside the structure.

[0217] Therefore, all graph components associated with the same tag will have the same properties associated with them. This reduces the inadvertent omission of specific graph components from search results due to accidental omission of metadata properties. Additionally, using tags associated with graph component property sets reduces user errors when setting metadata values, including typographical errors in property names.

[0218] Figure 8 An example graphical user interface (GUI) 800 is depicted that allows a user to define labels for graph components and associate those labels with properties of graph component metadata. Each property is given a name, a data type, and the user indicates whether the value should be stored in a structure. In this example, the user defines a label "paper version" and defines a property set associated with the label. The user includes the following properties in the property set for the "paper version" node: "version number" (integer), "section" (string), "final" (Boolean), and "redline completed" (Boolean). The "version number" property value will be stored in a structure in the gnode of the node with that label. When a user creates a new node in the represented graph, the user will be presented with a list of defined labels that may be associated with the created node. When a user associates a new node with the label "paper version", GOFS270 automatically creates metadata for the node, containing the properties defined for the label. The created metadata can have a default or blank metadata value, or the user can provide values ​​for the metadata properties in association with applying the label to the node.

[0219] 6. Application Examples

[0220] There are a variety of application types that can benefit from storing information as graph data at the file system level. In general, applications whose data is typically spread across multiple files will see performance gains by using the GOFS file system. More specifically, these types of applications may see faster I / O operations when stored and accessed using GOFS, either because graph functionality is implemented by the operating system rather than additional software, and / or because the data is stored in a format that is more natural to the data, allowing for more efficient access and searching. These types of applications include, but are not limited to:

[0221] ·AI

[0222] Geographic data

[0223] · Social networking, including food delivery, taxi apps, recruitment, for both storage and caching in mobile devices.

[0224] Software Development

[0225] Government security agencies

[0226] ·banking

[0227] Media Production

[0228] ·database

[0229] Embedded applications

[0230] Massive / distributed storage solutions in the cloud

[0231] To illustrate, software developers will use GOFS to have additional storage capabilities. Fig. 9 An example of graph admissible data is depicted, including an example graph 900 representing components of a software package having unidirectional relationships. Each relationship is associated with metadata (e.g., metadata in a structure) having the following key name and value "PKG=package_1.0". A developer can use the information in the metadata to identify the relationship associated with the value "package_1.0", for example, using a search operation that uses search criteria that identifies the metadata value. According to various embodiments, GOFS can be queried using queries in GraphQL or in a language similar to GraphQL. For example, the following graph query can be used to retrieve information from a graph 900 maintained by GOFS to identify nodes that match a particular graph query pattern and return specific information required to match the nodes, as follows:

[0232] match(“ / var / rpm / mypackage.pkg”)->[Relat.Pkg="package_1.0"]

[0233] return Relat.long_entry

[0234] / var / rpm / package.spec

[0235] / usr / bin / package

[0236] / usr / lib / libpackage.so

[0237] / etc / package.conf

[0238] As another example, many artificial intelligence (AI) based applications use neural networks to solve problems in different fields, including classification, pattern and sequence recognition, prediction, simulation, analysis, modeling, decision making, data processing, function approximation, etc. A neural network can be represented as a weighted graph structure with node layers, such as Fig. 9 This is depicted in the example diagram 910 of . This particular feature of neural networks makes GOFS a natural choice for storage, potentially making access and searching of data within GOFS more efficient.

[0239] As yet another example, geographic graph data uses a graph to represent geographic locations, which may be weighted to show distance. Fig. 9 Further depicted is an example graph 920B that models a road network 920A using the depicted nodes and relationships, where the relationship lengths represent the relationship weights (ie, distances) associated with various relationships. The nodes in graph 920B correspond to intersections, and the relationships correspond to the roads connecting them.

[0240] 7. Hardware Overview

[0241] An application, such as application 210, runs on a computing system and includes a combination of software and an allocation of resources from the computing system. Specifically, an application is a combination of integrated software components and an allocation of computing resources (such as memory and / or processes on a computing system for executing the integrated software components on a processor) that are dedicated to performing the described functions of the application.

[0242] According to one or more embodiments, one or more of the functions attributed to any of the processes described herein may be performed by Figure 4 In some embodiments, each technique and / or function described herein is automatically performed and can be implemented using one or more computer programs, other software elements, and / or digital logic in any of a general purpose computer or a special purpose computer while performing data retrieval, transformation, and storage operations involving interaction and transformation of the physical state of computer memory.

[0243] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform these technologies, or can include digital electronic devices (such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are permanently programmed to perform these technologies), or can include one or more general-purpose hardware processors that are programmed to perform these technologies according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs, or FPGAs with customized programming to implement these technologies. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hard-wiring and / or program logic to implement these technologies.

[0244] For example, Fig.10 1 is a block diagram illustrating a computer system 1000 upon which embodiments of the present invention may be implemented. Computer system 1000 includes a bus 1002 or other communication mechanism for communicating information, and a hardware processor 1004 coupled to bus 1002 for processing information. Hardware processor 1004 may be, for example, a general purpose microprocessor.

[0245] The computer system 1000 also includes a main memory 1006, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 1002 for storing information and instructions to be executed by the processor 1004. The main memory 1006 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by the processor 1004. When stored in a non-transitory storage medium accessible to the processor 1004, these instructions cause the computer system 1000 to become a special-purpose machine customized to perform the operations specified in the instructions.

[0246] The computer system 1000 also includes a read only memory (ROM) 1008 or other static storage device coupled to the bus 1002 for storing static information and instructions for the processor 1004. A storage device 1010, such as a magnetic disk, optical disk, or solid state drive, is provided and coupled to the bus 1002 for storing information and instructions.

[0247] The computer system 1000 may be coupled to a display 1012, such as a cathode ray tube (CRT), via the bus 1002 for displaying information to a computer user. An input device 1014, including alphanumeric and other keys, is coupled to the bus 1002 for communicating information and command selections to the processor 1004. Another type of user input device is a cursor control 1016, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 1004 and for controlling cursor movement on the display 1012. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0248] Computer system 1000 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that is combined with a computer system to make or program computer system 1000 into a special purpose machine. According to one embodiment, computer system 1000 performs the described techniques in response to processor 1004 executing one or more sequences of one or more instructions contained in main memory 1006. These instructions may be read into main memory 1006 from another storage medium, such as storage device 1010. Execution of the sequences of instructions contained in main memory 1006 causes processor 1004 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0249] The term "storage medium" as used herein refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical disks, magnetic disks, or solid-state drives, such as storage device 1010. Volatile media include dynamic memory, such as main memory 1006. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips, or cassette tapes.

[0250] Storage media are distinct from but can be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 1002. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0251] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 1004 for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 1000 may receive the data on the telephone line and use an infrared transmitter to convert the data into an infrared signal. An infrared detector may receive the data carried in the infrared signal and appropriate circuitry may place the data on the bus 1002. The bus 1002 carries the data to the main memory 1006, from which the processor 1004 retrieves and executes the instructions. The instructions received by the main memory 1006 may optionally be stored on the storage device 1010 before or after execution by the processor 1004.

[0252] Computer system 1000 also includes a communication interface 1018 coupled to bus 1002. Communication interface 1018 provides bidirectional data communication coupled to network link 1020, wherein network link 1020 is connected to local network 1022. For example, communication interface 1018 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection with a corresponding type of telephone line. As another example, communication interface 1018 can be a local area network (LAN) card to provide a data communication connection with a compatible LAN. A wireless link can also be implemented. In any such implementation, communication interface 1018 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0253] The network link 1020 typically provides data communication to other data devices through one or more networks. For example, the network link 1020 can provide a connection through the local network 1022 to a host computer 1024 or to data equipment operated by an Internet Service Provider (ISP) 1026. The ISP 1026, in turn, provides data communication services through the global packet data communication network, now commonly referred to as the "Internet" 1028. Both the local network 1022 and the Internet 1028 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 1020 and through the communication interface 1018, which carry the digital data to and from the computer system 1000, are example forms of transmission media.

[0254] Computer system 1000 can send messages and receive data, including program code, through the network(s), network link 1020, and communication interface 1018. In the Internet example, server 1030 can send the requested code for an application program through Internet 1028, ISP 1026, local network 1022, and communication interface 1018.

[0255] The received code may be executed by processor 1004 as it is received, and / or stored in storage device 1010 or other non-volatile storage for later execution.

[0256] 8. Software Overview

[0257] Fig.11 1 is a block diagram of a basic software system 1100 that may be used to control the operation of computer system 1000. Software system 1100 and its components, including their connections, relationships, and functions, are merely exemplary and are not meant to limit implementation of the example embodiment(s). Other software systems suitable for implementing the example embodiment(s) may have different components, including components with different connections, relationships, and functions.

[0258] Software system 1100 is provided for directing the operation of computer system 1000. Software system 1100, which may be stored on system memory (RAM) 1006 and fixed storage (eg, hard disk or flash memory) 1010, includes a kernel or operating system (OS) 1110.

[0259] The OS 1110 manages low-level aspects of computer operation, including managing the execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more application programs, represented as 1102A, 1102B, 1102C ... 1102N, can be "loaded" (e.g., transferred from fixed storage 1010 into memory 1006) for execution by the system 1100. Applications or other software intended for use on the computer system 1000 can also be stored as a downloadable set of computer-executable instructions, for example, for downloading and installation from an Internet location (e.g., a Web server, app store, or other online service).

[0260] The software system 1100 includes a graphical user interface (GUI) 1115 for receiving user commands and data in a graphical manner (e.g., "clicks" or "touch gestures"). In turn, these inputs can be operated by the system 1100 according to instructions from the operating system 1110 and / or (one or more) applications 1102. The GUI 1115 is also used to display the results of operations from the OS 1110 and (one or more) applications 1102, and the user can provide additional input or terminate the session (e.g., log out). Although Fig.11 GUI 1115 is depicted as being included in operating system 1110, but an operating system-provided GUI may be provided in a similar manner as application programs 1102A-N, i.e., as a process in user space.

[0261] The OS 1110 may execute directly on the bare hardware 1120 (e.g., processor(s) 1004) of the computer system 1000. Alternatively, a hypervisor or virtual machine monitor (VMM) 1130 may be inserted between the bare hardware 1120 and the OS 1110. In this configuration, the VMM 1130 acts as a software "buffer" or virtualization layer between the OS 1110 and the bare hardware 1120 of the computer system 1000.

[0262] VMM 1130 instantiates and runs one or more virtual machine instances ("clients"). Each client includes a "client" operating system (such as OS 1110), and one or more applications (such as (one or more) applications 1102) designed to execute on the client operating system. VMM 1130 presents a virtual operating platform to the client operating system and manages the execution of the client operating system.

[0263] In some cases, VMM 1130 can allow a guest operating system to run as if it were running directly on bare hardware 1120 of computer system 1000. In these cases, the same version of the guest operating system that is configured to execute directly on bare hardware 1120 can also execute on VMM 1130 without modification or reconfiguration. In other words, VMM 1130 can provide full hardware and CPU virtualization to guest operating systems in some cases.

[0264] In other cases, the guest operating system may be specially designed or configured to execute on VMM 1130 to improve efficiency. In these cases, the guest operating system is "aware" that it is executing on a virtual machine monitor. In other words, VMM 1130 may provide paravirtualization to the guest operating system in some cases.

[0265] A computer system process includes an allocation of hardware processor time, and an allocation of memory (physical and / or virtual) for storing instructions executed by the hardware processor, for storing data generated by the execution of instructions by the hardware processor, and / or for storing hardware processor state (e.g., contents of registers) between allocations of hardware processor time when the computer system process is not running. A computer system process runs under the control of an operating system and may run under the control of other programs executing on the computer system.

[0266] The purpose of presenting the above basic computer hardware and software is to illustrate the basic underlying computer components that can be used to implement the (one or more) example embodiments. However, the (one or more) example embodiments are not necessarily limited to any particular computing environment or computing device configuration. Instead, the (one or more) example embodiments can be implemented in any type of system architecture or processing environment that a person skilled in the art understands from this disclosure as being able to support the features and functions of the (one or more) example embodiments presented herein.

[0267] 9. Cloud computing

[0268] The term "cloud computing" is used generally herein to describe a computing model that enables on-demand access to a shared pool of computing resources, such as computer networks, servers, software applications, and services, and allows resources to be rapidly provisioned and released with minimal management effort or service provider interaction.

[0269] A cloud computing environment (sometimes referred to as a cloud environment or just a cloud) can be implemented in a variety of different ways to best suit different requirements. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the public. In contrast, a private cloud environment is generally intended for use by or within a single organization. A community cloud is intended to be shared by several organizations within a community; while a hybrid cloud includes two or more types of clouds (e.g., private, community, or public) bound together by data and application portability.

[0270] In general, the cloud computing model enables some of those responsibilities that might previously have been provided by an organization's own information technology department to instead be delivered as a service layer within a cloud environment for use by consumers (either internally or externally to the organization, depending on the public / private nature of the cloud). The precise definition of the components or features provided by or within each cloud service layer may vary depending on the specific implementation, but common examples include: Software as a Service (SaaS), where consumers use software applications running on a cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), where consumers can use software programming languages ​​and development tools supported by the supplier of the PaaS to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything under the runtime execution environment). Infrastructure as a Service (IaaS), where consumers can deploy and run arbitrary software applications, and / or provide processes, storage, networks, and other basic computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS), in which the consumer uses a database server or database management system running on a cloud infrastructure, while the DbaaS provider manages or controls the underlying cloud infrastructure, applications, and servers, including one or more database servers.

[0271] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive. The sole and exclusive indicator of the scope of the invention, and what the applicants intend as the scope of the invention, is the literal and equivalent range of the set of claims issuing from this application in the specific form in which such claims are issued, including any subsequent corrections.

Claims

1. A computer-implemented method comprising: maintaining a graph-organized file system (GOFS) in kernel space of one or more computing devices, the GOFS comprising (a) a plurality of node data structures representing a plurality of nodes, each of the plurality of node data structures storing an in-structure metadata value of a particular node characteristic, and (b) a plurality of edge entry data structures representing a set of one or more relationships between nodes of the plurality of nodes, each of the plurality of edge entry data structures storing an in-structure metadata value of a particular edge characteristic; performing a search operation on a graph represented by the GOFS based at least in part on search criteria including one or more of the particular node characteristic or the particular edge characteristic; wherein performing the search operation comprises generating a search operation result based at least in part on a metadata value in a structure accessing the specific edge characteristic; and Returns the result of the search operation.

2. The computer-implemented method of claim 1, wherein each node data structure comprises a content field for node content and an edge field for the plurality of edge entry data structures; wherein data of the GOFS is stored in a GOFS partition in a persistent storage device accessible by a particular computing device among the one or more computing devices, the GOFS partition comprising dedicated space for one or more of: a superblock, metadata, a block bitmap, a gnode bitmap, a gnode table, and data blocks; The method further includes receiving, by an operating system of a specific computing device, a file system command for the GOFS from an application in a user space; and The operating system executes the file system commands using the GOFS partition.

3. The computer-implemented method of claim 1 , further comprising: maintaining an index of one or more graph component properties corresponding to one or more of a set of in-structure metadata values, the set of in-structure metadata values ​​comprising: (a) the in-structure metadata value for the particular node property, and (b) the in-structure metadata value for the particular edge property; Wherein accessing one or more in-structure metadata values ​​in the set of in-structure metadata values ​​comprises accessing the one or more in-structure metadata values ​​in the index.

4. The computer-implemented method of claim 1, wherein: A set of in-structure metadata values ​​includes: (a) an in-structure metadata value of the specific node property, and (b) an in-structure metadata value of the specific edge property; Accessing one or more in-structure metadata values ​​in the set of in-structure metadata values ​​includes accessing the one or more in-structure metadata values ​​in a graph component data structure that includes one or both of the plurality of node data structures and the plurality of edge data structures.

5. The computer-implemented method of claim 1 , wherein: The graph-based file system includes a dedicated metadata space in a file system partition located in a persistent storage device, the dedicated metadata space including a plurality of data blocks; The dedicated metadata space stores extra-structural metadata values ​​of graph components of the graph; and The graph component of the graph includes the plurality of nodes and the set of one or more relationships.

6. The computer-implemented method of claim 5, wherein the extra-structural metadata values ​​are stored as key-value pairs.

7. The computer-implemented method of claim 5, wherein: The search criteria also includes an out-of-structure node metadata value of a second node characteristic; and Generating the search operation results is also based at least in part on accessing the dedicated metadata space to retrieve out-of-structure node metadata values ​​for one or more nodes of the plurality of nodes based at least in part on one or more identifiers of the one or more nodes.

8. The computer-implemented method of claim 7, wherein: The search criteria also include extra-structural relationship metadata values ​​for specific relationship properties; and Generating the search operation results is also based at least in part on accessing the dedicated metadata space to retrieve extra-structural relationship metadata values ​​of the one or more relationships based at least in part on one or more identifiers of one or more relationships in the set of one or more relationships.

9. The computer-implemented method of claim 5, further comprising: maintaining, in the partition, an index of one or more graph component properties corresponding to one or more extra-structural metadata values ​​of graph components of the graph; wherein the search criteria refers to at least one of the one or more graph component properties corresponding to the one or more external structure metadata values; and Wherein performing a search operation on the graph includes using the index.

10. The computer-implemented method of claim 5, wherein: The dedicated metadata space stores one or more extra-structural metadata values ​​of the superblock of the partition; as well as The method also includes accessing the dedicated metadata space to retrieve the one or more out-of-structure metadata values ​​for the Super Block based at least in part on a reserved Super Block value identifying the Super Block within the dedicated metadata space.

11. The computer-implemented method of claim 1 , wherein: The search criteria also include graph node patterns; and The performing a search operation includes performing pattern matching based on the graph node pattern.

12. The computer-implemented method of claim 1, wherein: Each node data structure of the plurality of node data structures comprises a visited flag; The performing a search operation on the graph includes tracking visited nodes using visited flags of the plurality of node data structures.

13. The computer-implemented method of claim 1, wherein: Each edge entry data structure of the plurality of edge entry data structures comprises a visited flag; The performing a search operation on the graph includes tracking visited edges using visited flags of the plurality of edge entry data structures.

14. The computer-implemented method of claim 1, wherein the GOFS is maintained in kernel space.

Images