Abstract: In response to a request to a file system to perform a requested update, a lock of a first node in a file system can be acquired, and an update of the first node can be performed while the lock of the first node is held. Also in response to the request, a lock of a second node can be acquired, and an update of the second node, which reflects the update of the first node, can be performed while the lock of the second node is held. The update of the first node can be independent of acquiring the lock of the second node. A file system can allow a pair of update operations to be performed in parallel where both operations include updating the same container node. Additionally, while a file system is running, new namespace types can be defined, and the file system can be extended to manage nodes within the new namespace types.

Abstract: Aspects of the subject matter described herein relate to maintaining consistency in a storage system. In aspects, one or more objects may be updated in the context of a transaction. In conjunction with updating the objects, logical copies of the objects may be obtained and modified. A request to write the updated logical copies is sent to a storage controller. The logical copies do not overwrite the original copies. In conjunction with sending the request, a data structure is provided for the storage controller to store on the disk. The data structure indicates the one or more objects that were supposed to be written to disk and may include verification data to indicate the content that was supposed to be written to disk. During recovery, this data structure may be used to determine whether all of the object(s) were correctly written to disk.

Abstract: Aspects of the subject matter described herein relate to checkpoints for a file system. In aspects, updates to the file system are organized into checkpoint buckets. When a checkpoint is desired, subsequent updates are directed to another checkpoint bucket. After global tables have been updated for updates in the current checkpoint bucket, a logical copy of the global tables is created. This logical copy is stored as part of the checkpoint data. To assist in recovery, a checkpoint manager may wait until all updates of the current checkpoint bucket have been written to storage before writing final checkpoint data to storage. This final checkpoint data may refer to the logical copy of the global tables and include a validation code to verify that the checkpoint data is correct.

Abstract: Aspects of the subject matter described herein relate to checkpoints for a file system. In aspects, updates to the file system are organized into checkpoint buckets. When a checkpoint is desired, subsequent updates are directed to another checkpoint bucket. After global tables have been updated for updates in the current checkpoint bucket, a logical copy of the global tables is created. This logical copy is stored as part of the checkpoint data. To assist in recovery, a checkpoint manager may wait until all updates of the current checkpoint bucket have been written to storage before writing final checkpoint data to storage. This final checkpoint data may refer to the logical copy of the global tables and include a validation code to verify that the checkpoint data is correct.

Abstract: Aspects of the subject matter described herein relate to storage allocation. In aspects, a hierarchical data structure is used to track allocation data for storage managed by a file system. The hierarchical data structure may have multiple levels with each level having data regarding a different granularity of storage. Portions of the hierarchical data structure may be locked independently of other portions of the hierarchical data structure. The hierarchical data structure may indicate that one or more portions of storage are for exclusive use by a directory. Extra space may be reserved in allocated space in anticipation of subsequent operations. Allocation requestors may obtain storage allocation from regions associated with different levels of the hierarchical data structure.

Abstract: Aspects of the subject matter described herein relate to error detection for files. In aspects, before allowing updates to a clean file, a flag marking the file as dirty is written to non-volatile storage. Thereafter, the file may be updated as long as desired. Periodically or at some other time, the file may be marked as clean after all outstanding updates to the file and error codes associated with the file are written to storage. While waiting for outstanding updates and error codes to be written to storage, if additional requests to update the file are received, the file may be marked as dirty again prior to allowing the additional requests to update the file. The request to write a clean flag regarding the file may be done lazily.

Abstract: Aspects of the subject matter described herein relate to checkpoints for a file system. In aspects, updates to the file system are organized into checkpoint buckets. When a checkpoint is desired, subsequent updates are directed to another checkpoint bucket. After global tables have been updated for updates in the current checkpoint bucket, a logical copy of the global tables is created. This logical copy is stored as part of the checkpoint data. To assist in recovery, a checkpoint manager may wait until all updates of the current checkpoint bucket have been written to storage before writing final checkpoint data to storage. This final checkpoint data may refer to the logical copy of the global tables and include a validation code to verify that the checkpoint data is correct.

Abstract: Aspects of the subject matter described herein relate to file system filters and transactions. In aspects, a filter may enlist to receive notification of events associated with a transaction. Afterwards, the filter may receive notification of a transaction event for which it has enlisted. In response to receiving notification of the transaction the filter may perform an action as appropriate. Aspects of the subject matter described herein may be applied to stacked and managed filters.

Abstract: Aspects of the subject matter described herein relate to transactions. In aspects, a consistency requester such as a shadow copy service requests to have a consistent view of a set of resources. In response, transactions that are in a problematic state are allowed to exit the problematic state while new and existing transactions that are not in the problematic state are allowed to perform any work except work that takes them into the problematic state. After no transactions are in the problematic state, a consistent view of the set of resources is available. This view may be used by the consistency requester as desired. Afterwards, the consistency requester may indicate that a consistent view is no longer needed. Transactions are then allowed to enter the problematic state. Transactions may also be allowed to enter the problematic state if a timeout elapses.

Abstract: Aspects of the subject matter described herein relate to maintaining consistency in a storage system. In aspects, one or more objects may be updated in the context of a transaction. In conjunction with updating the objects, logical copies of the objects may be obtained and modified. A request to write the updated logical copies is sent to a storage controller. The logical copies do not overwrite the original copies. In conjunction with sending the request, a data structure is provided for the storage controller to store on the disk. The data structure indicates the one or more objects that were supposed to be written to disk and may include verification data to indicate the content that was supposed to be written to disk. During recovery, this data structure may be used to determine whether all of the object(s) were correctly written to disk.

Abstract: Aspects of the subject matter described herein relate to file system filters and transactions. In aspects, a filter may enlist to receive notification of events associated with a transaction. Afterwards, the filter may receive notification of a transaction event for which it has enlisted. In response to receiving notification of the transaction the filter may perform an action as appropriate. Aspects of the subject matter described herein may be applied to stacked and managed filters.

Abstract: For each of one or more existing nodes in a file system, pending notifications of updates that have been performed on the node can be identified and sent to one or more other nodes. The file system can be opened for use, and one or more other nodes can be updated in response to the pending notifications while the file system is open for use. For example, this may be done in an operation for recovering from a crash of the file system. Also, a process for dealing with stale data in container nodes in a file system can include processing access requests according to a stale data scheme.

Abstract: In response to a request to a file system to perform a requested update, a lock of a first node in a file system can be acquired, and an update of the first node can be performed while the lock of the first node is held. Also in response to the request, a lock of a second node can be acquired, and an update of the second node, which reflects the update of the first node, can be performed while the lock of the second node is held. The update of the first node can be independent of acquiring the lock of the second node. A file system can allow a pair of update operations to be performed in parallel where both operations include updating the same container node. Additionally, while a file system is running, new namespace types can be defined, and the file system can be extended to manage nodes within the new namespace types.

Abstract: Aspects of the subject matter described herein relate to antivirus protection and transactions. In aspects, a filter detects that a file is participating in a transaction and then may cause the file to be scanned together with any changes that have made to the file during the transaction. After a file is scanned, a cache entry may be updated to indicate that the file is clean. The cache entry may be used subsequently for like-type states. For example, if the file was scanned inside a transaction, the cache entry may be used later in the transaction. If the file was scanned outside a transaction, the cache entry may be used later for requests pertaining to files not in a transaction. Cache entries may be discarded when they are invalid or no longer useful.

Abstract: Discovering transaction managers participating in a transaction. A method may be practiced, for example, in a commit tree topology including a number of transaction managers to manage transactions. The transactions include a set of operations that are all performed if a transaction is completed or all aborted if a transaction is not completed. The transaction managers store transaction result information to allow recovery of a transaction in case of system failure. The method includes receiving at a first transaction manager, a token from a second transaction manager on a machine external to the first transaction manager. The token specifies that the first transaction manager is the originator of the token. The token is associated with a transaction. The first transaction manager identifies that it has not previously participated in the transaction associated with the token. A transaction manager is identified that is participating in the transaction associated with the token.

Abstract: Minimizing transaction managers. A method that may be practiced in a commit tree topology including a plurality of transaction managers to manage transactions. The transactions include a set of operations that are all performed if a transaction is completed or all aborted if a transaction is not completed. The transaction managers store transaction result information to allow recovery of a transaction in case of system failure. The method includes acts for minimizing storage overhead by minimizing the number of transaction managers used to coordinate transactions. The method includes identifying a set of transaction managers. A first transaction manager is selected from among the set of transaction managers. A second transaction manager is identified from among the set of transaction managers that is always available when the first transaction manager is available. Messages are redirected from a subordinate associated with the first transaction manager to the second transaction manager.

Abstract: Discovering transaction managers participating in a transaction. A method may be practiced, for example, in a commit tree topology including a number of transaction managers to manage transactions. The transactions include a set of operations that are all performed if a transaction is completed or all aborted if a transaction is not completed. The transaction managers store transaction result information to allow recovery of a transaction in case of system failure. The method includes receiving at a first transaction manager, a token from a second transaction manager on a machine external to the first transaction manager. The token specifies that the first transaction manager is the originator of the token. The token is associated with a transaction. The first transaction manager identifies that it has not previously participated in the transaction associated with the token. A transaction manager is identified that is participating in the transaction associated with the token.

Abstract: An external request to perform a file operation within a resource manager is received. The resource manager selects a resource manager file identifier that is to be an attribute of a file associated with the file operation. The file operation and the resource manager file identifier are logged in a log entry of a log. Subsequent to logging the log entry, the log entry is accessed during a forward pass through the log, for example, during a roll-forward recovery. If it is determined that the resource manager file identifier in the log entry is assigned to the file, the first log entry is not processed. On the other hand, if it is determined that the resource manager file identifier in the log entry is not assigned to the file, the resource manager file identifier is selected to be assigned to a file when the first log entry is processed.

Abstract: Nodes in a distributed system maintain virtual times according to specified rules. Each node can associate its virtual time with transactional messages that are transferred to other nodes and with log entries that are written to a log. A reference entry, which corresponds to an arbitrary point in time, is selected from a first log associated with a first node. A reference virtual time associated with the reference entry is identified. A matching entry, with an associated virtual time that appropriately corresponds to the reference virtual time, is selected from a second log associated with a second node. The first node is caused to roll-forward to the arbitrary time by processing the first log up to the reference entry. The second node is caused to roll-forward to the arbitrary time by processing the second log up to the matching entry.

Abstract: The location of appropriate undo data necessary for reversing an effect of an operation performed at a computer system is identified during a forward pass through a log. A cycle count can be used to determine if appropriate undo data is stored in an object or is stored in auxiliary storage. If appropriate undo data is stored in an object and the undo data would be potentially lost by processing a redo log entry to modify the contents of the object, the appropriate undo data is copied to auxiliary storage. In some embodiments, a secondary computer system receives log entries from a primary computer system. The secondary computer system can identify undo data necessary to reverse an effect of an operation performed at the secondary computer system from received log entries. Identified undo data can be copied auxiliary storage at the secondary computer system.