Abstract: The present invention uniquely names storage devices in a global storage environment with hierarchical storage domains. In particular, according to one or more embodiments of the present invention a storage device (e.g., a disk) is connected at a particular location within the global storage environment. That particular location is associated with a path of each of one or more hierarchical storage domains in which the storage device is located. Accordingly, a name is assigned to the storage device that is the path of the hierarchical storage domains in which the storage device is located.

Abstract: The present invention uniquely names storage devices in a global storage environment with hierarchical storage domains. In particular, according to one or more embodiments of the present invention a storage device (e.g., a disk) is connected at a particular location within the global storage environment. That particular location is associated with a path of each of one or more hierarchical storage domains in which the storage device is located. Accordingly, a name is assigned to the storage device that is the path of the hierarchical storage domains in which the storage device is located.

Abstract: The present invention uniquely names storage devices in a global storage environment with hierarchical storage domains. In particular, according to one or more embodiments of the present invention a storage device (e.g., a disk) is connected at a particular location within the global storage environment. That particular location is associated with a path of each of one or more hierarchical storage domains in which the storage device is located. Accordingly, a name is assigned to the storage device that is the path of the hierarchical storage domains in which the storage device is located.

Abstract: A system and method verifies and restores the consistency of inode to pathname mappings. In a first embodiment, an off-line verification procedure is modified to verify and correct the primary name inode to pathname mapping information within inodes of a file system. In a second embodiment, an on-line file system verification process is modified to verify inode to pathname mapping information upon the loading of each inode within the file system.

Abstract: A system and method maintains mappings from data containers to their parent directories within a file system of a storage system. Each inode is modified to include a primary name data structure comprising a parent directory inode and a parent directory cookie value. The parent directory cookie value identifies a particular directory entry within a specified block of a directory identified by parent directory inode. An alternate name file is utilized to store alternate names, such as those associated with hard links.

Abstract: The present invention provides techniques for managing ownership (i.e., control) of one or more memory buffer (mbuf) data structures within a network subsystem and a storage subsystem of a storage operating system implemented in a storage system. When the storage system receives data to be written to a storage medium, the network subsystem stores the received data in one or more variable-length chains of mbufs. Unlike conventional approaches, the received data is not subsequently copied out of the mbufs into fixed-sized data buffers for use by the storage subsystem. Instead, the storage subsystem can directly manipulate the received data stored in the mbufs. By eliminating the steps of copying data out of the mbufs and into fixed-sized data buffers, the invention reduces the amount of time and system resources consumed by the storage system when writing blocks of received data to disk storage.

Abstract: The present invention provides a technique for efficiently generating and validating external file handles at a storage operating system of a filer. According to one aspect of the technique, the storage operating system associates a unique internal file handle with each file or directory stored in the filer. This unique internal file handle is used to generate a corresponding external file handle. Unlike previous approaches, the internal file handles' representations do not change depending on the location of their corresponding files or directories, e.g., on-disk or in-core, within the filer, thereby simplifying file management within the filer. According to another aspect of the inventive technique, the filer executes a file-handle validation procedure to determine whether an external file handle received with a file access request has become invalid (or “stale”) as a result of an NVRAM failure in the filer.

Abstract: A system and method maintains mappings from data containers to their parent directories within a file system of a storage system. Each inode is modified to include a primary name data structure comprising a parent directory inode and a parent directory cookie value. The parent directory cookie value identifies a particular directory entry within a specified block of a directory identified by parent directory inode. An alternate name file is utilized to store alternate names, such as those associated with hard links.

Abstract: A system and method verifies and restores the consistency of inode to pathname mappings. In a first embodiment, an off-line verification procedure is modified to verify and correct the primary name inode to pathname mapping information within inodes of a file system. In a second embodiment, an on-line file system verification process is modified to verify inode to pathname mapping information upon the loading of each inode within the file system.

Abstract: A system and method verifies and restores the consistency of inode to pathname mappings. In a first embodiment, an off-line verification procedure is modified to verify and correct the primary name inode to pathname mapping information within inodes of a file system. In a second embodiment, an on-line file system verification process is modified to verify inode to pathname mapping information upon the loading of each inode within the file system.

Abstract: The present invention provides a technique for efficiently generating and validating external file handles at a storage operating system of a filer. According to one aspect of the technique, the storage operating system associates a unique internal file handle with each file or directory stored in the filer. This unique internal file handle is used to generate a corresponding external file handle. Unlike previous approaches, the internal file handles' representations do not change depending on the location of their corresponding files or directories, e.g., on-disk or in-core, within the filer, thereby simplifying file management within the filer. According to another aspect of the inventive technique, the filer executes a file-handle validation procedure to determine whether an external file handle received with a file access request has become invalid (or “stale”) as a result of an NVRAM failure in the filer.

Abstract: Software implementing a volume location service on a computer is responsible for instructing clients where they can find volumes on a distributed file system storing instances of desired resources. A user queries the volume location service software for the location of instances of a desired resource. The user can also specify attributes (e.g., read-only access) to reduce the number of returned hosts. The volume location service software accesses a back-end database for the hosts with the optional attribute storing resource instances. The back-end database stores information about what hosts store instances of what resources. The back-end database is pluggable, and can be changed as desired by the administrator of the volume location service. The volume location service software then returns to the user the found hosts.

Abstract: In a hierarchically organized distributed file system, resources belong to the containers in which they are located. These resources do not have to be co-located with the, containers in which they are stored, but can be distributed over the file system. To locate a desired resource, the unique name of the resource is determined. Moving upward through the containers in the hierarchically organized distributed file system, the lowest container with a location service is determined. The location service is queried for known instances of the resource. Any instance of the resource returned from the location service can then be utilized. Semantic contexts can also be applied to the network to control access or usage of both the location services and resource instances. The use of semantic contexts allows for improvements in network usage, security, resource allocation, and the like.

Abstract: When a volume is created, a Modified Files List (MFL) is established and an epoch timestamp, identifying an important point in time, is set for the volume. Entries are inserted into the MFL whenever files are first added to or changed on the volume. Entries are flagged with the epoch timestamp in which they are added to the MFL. Entries are removed from the MFL when files are restored to an already-archived condition or are deleted from the volume. A system administrator can declare a new epoch at any time, and will declare a new epoch before performing a backup. The system administrator will select an epoch for backup purposes. The files inserted into the MFL before the selected epoch timestamp are enumerated and archived using a backup tool. After the backup tool turns off a file's data and metadata archive bits, the corresponding entry is removed from the MFL.

Abstract: An infrastructure on a file server registers one or more replication modules to support file replication across a plurality of file servers. Each replication module can support file replication for any number of volumes on the file server, but each volume can be replicated by at most one replication module. The replication modules register with the replication module by identifying themselves to the replication infrastructure, identifying those activities the replication modules wish to be notified about, and identifying those volumes each replication module will support. The replication infrastructure tracks each volume. When a watched activity occurs, the replication infrastructure notifies the supporting replication module. Finally, when the replication infrastructure receives an update from the replication module, the replication infrastructure performs the update to the supported volume.