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. 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: A file system uses data integrity techniques that are a selectable attribute of a file system object. Some file system objects have integrity on for various accesses, while other file system objects do not. Different default settings can be provided for different file system objects. Such a setting for a file system object can be changed to and from having integrity on. Given a file system object with an attribute, the file system provides file system operations for which the data integrity operation used on the file system object depends on this attribute. Such operations include, but are not limited to, operations for changing the attribute, creating file system objects with such attributes, providing and changing default settings for such attributes, and writing data to and reading data from files, which use different data integrity techniques based on this attribute.

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 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: A file system uses data integrity techniques that are a selectable attribute of a file system object. Some file system objects have integrity on for various accesses, while other file system objects do not. Different default settings can be provided for different file system objects. Such a setting for a file system object can be changed to and from having integrity on. Given a file system object with an attribute, the file system provides file system operations for which the data integrity operation used on the file system object depends on this attribute. Such operations include, but are not limited to, operations for changing the attribute, creating file system objects with such attributes, providing and changing default settings for such attributes, and writing data to and reading data from files, which use different data integrity techniques based on this attribute.

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 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: A file system uses data integrity techniques that are a selectable attribute of a file system object. Some file system objects have integrity on for various accesses, while other file system objects do not. Different default settings can be provided for different file system objects. Such a setting for a file system object can be changed to and from having integrity on. Given a file system object with an attribute, the file system provides file system operations for which the data integrity operation used on the file system object depends on this attribute. Such operations include, but are not limited to, operations for changing the attribute, creating file system objects with such attributes, providing and changing default settings for such attributes, and writing data to and reading data from files, which use different data integrity techniques based on this attribute.

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 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 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 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 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 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: 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: 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: 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. 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.