Abstract: In some examples, a multi-node system may access physical storage divided into extents and further arranged into extent groups that may be allocated on demand as thin provisioned storage in response to write requests. Protection class instances are set with specified data protection capabilities. Each instance acts as a logical unit having a distinct addressable block storage space from the extent groups allocated thereto. The extents in an extent group to be allocated to a given protection class instance may vary depending on the protection class capabilities. Management information for the extents, extent groups, and protection classes may be stored in mirrored devices separate from the write data stored in the extents for providing redundant protection to the management information and for increasing the availability of write data in the event of a failure that may cause data loss at one or more locations in the system.

Abstract: In some examples, both object data and corresponding metadata are stored on thin provisioned block storage in which blocks for the storage of the object data and the metadata are dynamically provisioned from a shared pool. For instance, the metadata may be stored on the block storage using a tree data structure that may grow proportionally with the corresponding stored object data. The object storage may automatically adapt to the size and number of objects being stored, and storage space for metadata may be allocated dynamically on demand. Additionally, some implementations include storing data across multiple trays. For instance, a plurality of storage extents of an extent group may be allocated across a plurality of storage devices on multiple trays. The extent allocation may be tray-aware by allocating extents to maximize the probability that data remains available/recoverable in the presence of a failure in one or more trays.

Abstract: Example implementations are directed to restoration of data not only from the servers, but also from the clients connected to the server. Algorithms are incorporated to identify content that was created or modified after the last backup. This algorithm also identifies and resolves changes in the mount points for shared folders, preventing information leakage. When the server recovers from a failure, it notifies the clients about the recovery on their next connection. Each client then determines the current state of its mount points and file paths and compares them with the server's mount points and file paths. After the comparison, the client comprehends and indicates the mount point differences by renaming them and sends entire local data (all files, folders, mount points) to the server. The server reconciles the differences.

Abstract: Example implementations described herein are directed to a transaction query engine involving a token that is generated by the server and sent to the corresponding the client. The client uses the token to query transactions made on the server. The token can include mountpoint information detailing shared and private information of the filesystems, transaction identifiers identifying transactions of a filesystem, and a filesystem identifier to identify the corresponding filesystem. The server processes this token and updates the token based on the transaction information of the filesystem, and sends the token back to the corresponding client.

Abstract: In some examples, a multi-node system may access physical storage divided into extents and further arranged into extent groups that may be allocated on demand as thin provisioned storage in response to write requests. Protection class instances are set with specified data protection capabilities. Each instance acts as a logical unit having a distinct addressable block storage space from the extent groups allocated thereto. The extents in an extent group to be allocated to a given protection class instance may vary depending on the protection class capabilities. Management information for the extents, extent groups, and protection classes may be stored in mirrored devices separate from the write data stored in the extents for providing redundant protection to the management information and for increasing the availability of write data in the event of a failure that may cause data loss at one or more locations in the system.

Abstract: In some examples, both object data and corresponding metadata are stored on thin provisioned block storage in which blocks for the storage of the object data and the metadata are dynamically provisioned from a shared pool. For instance, the metadata may be stored on the block storage using a tree data structure that may grow proportionally with the corresponding stored object data. The object storage may automatically adapt to the size and number of objects being stored, and storage space for metadata may be allocated dynamically on demand. Additionally, some implementations include storing data across multiple trays. For instance, a plurality of storage extents of an extent group may be allocated across a plurality of storage devices on multiple trays. The extent allocation may be tray-aware by allocating extents to maximize the probability that data remains available/recoverable in the presence of a failure in one or more trays.

Abstract: A redundant array of independent nodes are networked together. Each node executes an instance of an application that provides object-based storage. The nodes are grouped into systems each having multiple nodes. Objects in the systems have access control lists (ACLs) associated therewith. A method of providing a search key to each ACL in any one system comprises: selecting a region for each metadata object pertaining to the objects in the system; and generating, for each ACL associated with an object in the system, an ACL ID (identifier) as a search key which includes the region number of the region selected for the metadata object pertaining to the object, a region map level corresponding to the region selected, and a monotonically increasing counter value that is automatically incremented each time an ACL ID is generated. The ACL ID remains unique during reconfiguration via splitting/merging existing distributed portions of the database.

Abstract: Example implementations described herein are directed to a transaction query engine involving a token that is generated by the server and sent to the corresponding the client. The client uses the token to query transactions made on the server. The token can include mountpoint information detailing shared and private information of the filesystems, transaction identifiers identifying transactions of a filesystem, and a filesystem identifier to identify the corresponding filesystem. The server processes this token and updates the token based on the transaction information of the filesystem, and sends the token back to the corresponding client.

Abstract: Example implementations are directed to restoration of data not only from the servers, but also from the clients connected to the server. Algorithms are incorporated to identify content that was created or modified after the last backup. This algorithm also identifies and resolves changes in the mount points for shared folders, preventing information leakage. When the server recovers from a failure, it notifies the clients about the recovery on their next connection. Each client then determines the current state of its mount points and file paths and compares them with the server's mount points and file paths. After the comparison, the client comprehends and indicates the mount point differences by renaming them and sends entire local data (all files, folders, mount points) to the server. The server reconciles the differences.

Abstract: A redundant array of independent nodes are networked together. Each node executes an instance of an application that provides object-based storage. The nodes are grouped into systems each having multiple nodes. Objects in the systems have access control lists (ACLs) associated therewith. A method of providing a search key to each ACL in any one system comprises: selecting a region for each metadata object pertaining to the objects in the system; and generating, for each ACL associated with an object in the system, an ACL ID (identifier) as a search key which includes the region number of the region selected for the metadata object pertaining to the object, a region map level corresponding to the region selected, and a monotonically increasing counter value that is automatically incremented each time an ACL ID is generated. The ACL ID remains unique during reconfiguration via splitting/merging existing distributed portions of the database.