Abstract: A method for file system reorganization in the presence of inline compression includes obtaining a virtual block pointer for an original compressed segment to be reorganized, the original compressed segment comprising compressed allocation units of data stored in a storage system, wherein the virtual block pointer comprises an extent list identifying the compressed allocation units in the original compressed segment and a pointer to where the original compressed segment is stored; copying only the referenced compressed allocation units in the original compressed segment to a new compressed segment in a substantially contiguous manner; updating the extent list to identify the referenced compressed allocation units in the new compressed segment, and the pointer to where the new compressed segment is stored; and freeing the original compressed segment.

Abstract: Logging changes to file system metadata using a single log hold per cached block of metadata. A metadata log including log entries is maintained in persistent storage, and each log entry in the metadata log contains metadata modified by a corresponding file system request. A single log hold is stored for each block of cached metadata. The single log hold for a given block of cached metadata indicates a file system request that modifies the metadata contained in the block, and that corresponds to a log entry located the closest, of all log entries corresponding to file system requests that modify metadata contained in the block, to a head of the metadata log.

Abstract: Managing a file system to avoid unnecessary replay of a transaction log. The file system may reside on a non-volatile storage medium having an associated transaction log residing on a non-volatile storage medium, the transaction log including a plurality of log entries, and each log entry representing one or more changes to metadata of the file system. The file system may include a first data structure including a status parameter, a value of which is indicative of whether to replay the transaction log when the file system is initialized. It may be determined whether the one or more changes to metadata represented by each of the plurality of log entries have been written in place in the file system. In response to the determination, the status parameter may be set to a value indicative of the determination.

Abstract: A method, computer program product, and computing system for defining a transactional log file for a data storage system including a data array. A first plurality of IO requests for the data storage system is processed. The transactional log file is updated to include information concerning the first plurality of IO requests. An IO pointer is defined to locate a specific IO request of the first plurality of IO requests within the transactional log file. File system metadata is defined on the data array for the data storage system.

Abstract: A method, computer program product, and computing system for defining a transactional log file for a data storage system including defining a transactional log file for a data storage system including a data array. A plurality of IO requests for the data storage system are processed. The transactional log file is updated to include information concerning the plurality of IO requests, wherein the information includes an LGT indicator for each of the plurality of IO requests. The occurrence of a malfunction within the data storage system is sensed.

Abstract: A technique for managing a file system includes dividing the addressable space of a file system into multiple subspaces: a data subspace for user data; an inode subspace for inodes describing the user data; and an MDB (metadata block) subspace for indirect blocks and/or directory structures pertaining to the user data. In response to storage requests to write user files to the file system, the file system stores user data of the files in the data subspace, stores inodes pertaining to the user files in the inode subspace, and stores indirect blocks and/or directories in the MDB subspace.

Abstract: An improved technique generates formatted file system metadata in increments only when metadata for those increments are specifically requested. A location on a storage volume designated for storing file system metadata is read and tested to determine whether it stores a predetermined pattern indicating an unformatted state. If the pattern is found, metadata for the designated location are generated and returned. Otherwise, metadata are returned as initially read from the storage volume.

Abstract: A dataset is recovered after a server reboot while clients access the dataset. In response to the reboot, not-yet-completed transactions in a log are parsed to create, for each of the dataset blocks modified by these active transactions, a respective block replay list of the active transactions that modify the block. Once the block replay lists have been created, clients may access specified blocks of the dataset after on-demand recovery of the specified blocks. The on-demand recovery is concurrent with a background recovery task that replays the replay lists. To accelerate log space recovery, the parsing of the log inserts each replay list into a first-in first-out queue serviced by multiple replay threads. The queue can also be used as the cache writeback queue, so that the cache index is used for lookup of the replay list and the recovery state of a given block.

Abstract: A networked data storage system includes a primary volume and a pointer-based virtual secondary volume. The secondary volume has B-tree checkpoints of the state of a primary filesystem of the primary volume. Intermediate syncpoints are declared between checkpoint checkpoints. The syncpoints are logical locations on the secondary volume where the B-tree is known to be in a consistent state. The frequency of syncpoints may be set by an administrator in units of blocks, i.e., a syncpoint to be taken every n blocks. Before performing a B-tree split, entire images of the leaves and parent node involved in the split are written to an intent log in a relatively fast transaction that may comprise a single I/O operation to contiguous memory. Movement of data between leaf nodes and changes to the parent nodes as a result of the split operation proceed asynchronously. In the event of a reboot before the split operation is complete, the intent log is used to complete the split transaction from the most recent syncpoint.

Abstract: In a file server, a file system is built upon a volume of data storage. The file system includes multiple cylinder groups. Each cylinder group includes file system blocks. The file system blocks include allocated blocks and free blocks. The volume includes slices of storage, and each slice stores at least one of the cylinder groups. A hierarchical slice map has a top level that includes a count of free blocks in the file system, an upper level that includes a count of free blocks in groups of the slices, an intermediate level that includes a count of the free blocks in sub-groups of the slices, and a bottom level that includes a count of the free blocks in each slice of storage. To find a free block for allocation to a file, the slice map hierarchy is searched in a top-down fashion.

Abstract: A replication process using snapshots to maintain information regarding changes made to a production data set following a point in time. In some embodiments, the production data set may be a file system and the snapshot may store information relating to changes made to both previously-allocated and newly-allocated data blocks. When a change is made to a previously-allocated data block, the original contents for the data block may be copied to a save volume prior to being overwritten by the new data, while for a newly-allocated data block no data may be copied to the save volume. An entry may also be created in a map identifying each changed data block. A replication process may then read the block map to identify data blocks storing new data to should be replicated to a replication data set, such that the replication data set remains a copy of the production data set.