The described technology is generally directed an extension to the IFS domains architecture, referred to herein as filter domains. IFS domains allows tagging of files in a tree-like dataset. Thus, a domain can be defined at the root of the dataset such as the topmost directory under which all files reside. These domains are inherently hierarchichal, path-based entities. Filter domains extends this organization to allow domains to be applied beyond hierarchical tree structures in order to also provide arbitrary grouping of file objects based on any suitable membership condition.

Techniques described herein relate to systems and methods of data storage, and more particularly to providing layering of file system functionality on an object interface. In certain embodiments, file system functionality may be layered on cloud object interfaces to provide cloud-based storage while allowing for functionality expected from a legacy applications. For instance, POSIX interfaces and semantics may be layered on cloud-based storage, while providing access to data in a manner consistent with file-based access with data organization in name hierarchies. Various embodiments also may provide for memory mapping of data so that memory map changes are reflected in persistent storage while ensuring consistency between memory map changes and writes. For example, by transforming a ZFS file system disk-based storage into ZFS cloud-based storage, the ZFS file system gains the elastic nature of cloud storage.

A computer may receive a request to generate a snapshot view of the enterprise network infrastructure. The computer may implement a multithread process to contemporaneously query a plurality of blade servers and server enclosures within the entire network infrastructure. The computer may contemporaneously receive a plurality of information files from the queried network resources (e.g. the blade servers, server enclosures). In active state modes, the computer may push firmware update binaries to the network resources. In a server processing and an active state mode, the computer may implement a multithreaded process to push the firmware update binaries to standalone servers or blade servers that can be accessed directly. In a blade enclosure processing and an active state mode, the computer may implemented a nested multi-threader, using child threads nested within a parent thread to a blade server enclosure to push firmware update binaries to blade servers in the enclosure.

In an embodiment, two or more storage systems are requested to prepare respective local checkpoints for a dataset, wherein each of the two or more storage systems stores portion of the dataset. The two or more storage systems are determined to have established the checkpoint. In response to determining that the local checkpoints have been established, a coordinated checkpoint is completed.

A database system receives a query and determines that the query includes an inner join between a parent table and a child table. The database system determines that the following relationships exists between the parent table and the child table: referential integrity (“RI”) between a primary key attribute (pk) in the parent table and a foreign key attribute (fk) in the child table and a temporal relationship constraint (“TRC”) between a period attribute in the parent table and a TRC-attribute in the child table. The database system determines that the query satisfies non-temporal join elimination conditions and temporal join elimination conditions and that the query contains no other qualification conditions on the parent table's period attribute and eliminates the inner join when planning execution of the query.

The technology described herein efficiently determines whether a real inode is shared among views, or owned. In-memory data structures include a view snapshot generation counter that is increased as a snapshot that generates a view is created, and an inode total weight. An in-memory virtual inode cache dataset for a filesystem object associated with the view is instantiated with the value of snapshot generation counter, sharing-related data based on the inode mapping file entry for the object, and an inode access weight. To determine whether the inode is shared (and needs to be split), such as on a write to the object, the in-memory data is evaluated. The real inode is shared if the generation counters are unequal, if the sharing-related data indicates sharing at an intermediate indirect block level, or indicates sharing at the inode level and the inode access weight is less than the inode total weight.

The present disclosure is related to methods, systems, and machine-readable media for determining shared nodes between snapshots using probabilistic data structures. A unique identifier can be assigned to each node of a first tree data structure corresponding to a first snapshot of a virtual computing instance (VCI). A first probabilistic data structure representing the first tree data structure can be created that includes hashes of the identifiers assigned to the nodes of the first tree data structure. A unique identifier can be assigned to each node of a second tree data structure corresponding to a second snapshot of the VCI. A second probabilistic data structure representing the second tree data structure can be created that includes hashes of the identifiers assigned to the nodes of the second tree data structure. A particular node of the second tree data structure can be determined to be shared by the first tree data structure responsive to a determination that the first probabilistic data structure includes a hash of an identifier assigned to the particular node.

Described is hard link handling when a directory snapshot exists that includes the hard link's connected file object. A hard link is created by allocating a virtual inode number for the hard link, with the virtual inode number mapped to a real inode number that identifies a real inode of the file object; the hard link is assigned weight. A total weight associated with the real inode is increased by the hard link weight, and a hard link data store is updated with an entry for the hard link. Upon receiving data write request to the hard link, weight data determines that the file object is shared as a result of the snapshot; the hard link is disassociated from the real inode file, and associated with a new real inode number and new real inode of a new file object. The data is written based on the new real inode.

An identification of a new primary snapshot created for a primary storage system is received. A change tracking time window that is at least a portion of a period between a first capture time associated with a previous primary snapshot and a second capture time associated with the new primary snapshot is determined. Entries of a storage log of the primary storage system occurring within the change tracking time window are analyzed to coalesce changes identified in the entries of the storage log occurring within the change tracking time window into a change tracking result set. The change tracking result set is used to identify at least a portion of data changes between the previous primary snapshot and the new primary snapshot to capture in a new backup snapshot stored at a secondary storage system.

An Application Data Management System (ADMS) enables an application file system to be mounted at any selected reconstruction time (T.sub.R). If the reconstruction time T.sub.R falls intermediate snapshot creation timepoints, the ADMS creates a version of the application file system at the selected reconstruction time T.sub.R using a snapshot of the data file from a previous application file system snapshot creation timepoint, and a snapshot of the log file from a subsequent application file system snapshot creation timepoint. The ADMS uses the snapshot of the log file from the subsequent snapshot creation timepoint to replay transactions on the snapshot of the data file from the previous snapshot creation timepoint up to the selected reconstruction time T.sub.R. This enables the state of the application file system to be recreated and mounted at any arbitrary selected reconstruction time, even if the selected reconstruction time is not coincident with snapshot creation timepoints.