Abstract: The techniques and systems described herein determine whether or not to implement reparse behavior in association with a file or a directory access. A file system and/or a file system filter can receive, from a host system component, a request to open a file or a directory. While attempting to access the file or the directory, a reparse tag associated with an intermediate directory is encountered. The file system can then determine whether a next node, along an access path for the file or the directory to be opened, exists in the intermediate directory. That is, the file system can look beyond the reparse tag and into the intermediate directory to determine if the next node exists. Subsequently, the file system and/or the file system filter can decide whether to implement reparse behavior based on the reparse tag and whether the next node exists in the intermediate directory.

Abstract: The techniques and systems described herein reduce the amount of storage resources consumed by containers by creating placeholder files in container namespaces. The placeholder files are associated with read-only access to corresponding shared files stored in a read-only namespace. The read-only namespace can be accessible to multiple different containers. This increases the storage density for a storage unit because more containers can be executed from the same storage unit. The techniques and systems described herein further reduce the amount of storage resources consumed by containers by creating placeholder directories. The techniques and systems described herein also reduce the amount of memory storage resources consumed by containers to execute files by using a shared execution memory area.

Abstract: The techniques and systems described herein reduce the amount of storage resources consumed by containers by creating placeholder files in container namespaces. The placeholder files are associated with read-only access to corresponding shared files stored in a read-only namespace. The read-only namespace can be accessible to multiple different containers. This increases the storage density for a storage unit because more containers can be executed from the same storage unit. The techniques and systems described herein further reduce the amount of storage resources consumed by containers by creating placeholder directories. The techniques and systems described herein also reduce the amount of memory storage resources consumed by containers to execute files by using a shared execution memory area.

Abstract: The techniques and systems described herein determine whether or not to implement reparse behavior in association with a file or a directory access. A file system and/or a file system filter can receive, from a host system component, a request to open a file or a directory. While attempting to access the file or the directory, a reparse tag associated with an intermediate directory is encountered. The file system can then determine whether a next node, along an access path for the file or the directory to be opened, exists in the intermediate directory. That is, the file system can look beyond the reparse tag and into the intermediate directory to determine if the next node exists. Subsequently, the file system and/or the file system filter can decide whether to implement reparse behavior based on the reparse tag and whether the next node exists in the intermediate directory.

Abstract: A thinly provisioned storage system detects whether physical storage capacity is available when there is a request to allocate storage capacity, prior to data being written to the storage system. In particular, at the time when the file system allocates storage, such as when creating a file or performing an extending write (append) operation, allocating storage to an unallocated region of a sparse file, defragmenting a file, and the like, a storage system can verify that actual physical storage capacity is available. Thus, if there is insufficient actual physical capacity at the time when a storage allocation is attempted, then an error message can be sent and remedial action can be taken.

Abstract: A thinly provisioned storage system detects whether physical storage capacity is available when there is a request to allocate storage capacity, prior to data being written to the storage system. In particular, at the time when the file system allocates storage, such as when creating a file or performing an extending write (append) operation, allocating storage to an unallocated region of a sparse file, defragmenting a file, and the like, a storage system can verify that actual physical storage capacity is available. Thus, if there is insufficient actual physical capacity at the time when a storage allocation is attempted, then an error message can be sent and remedial action can be taken.

Abstract: A thinly provisioned storage system detects whether physical storage capacity is available when there is a request to allocate storage capacity, prior to data being written to the storage system. In particular, at the time when the file system allocates storage, such as when creating a file or performing an extending write (append) operation, allocating storage to an unallocated region of a sparse file, defragmenting a file, and the like, a storage system can verify that actual physical storage capacity is available. Thus, if there is insufficient actual physical capacity at the time when a storage allocation is attempted, then an error message can be sent and remedial action can be taken.

Abstract: A thinly provisioned storage system detects whether physical storage capacity is available when there is a request to allocate storage capacity, prior to data being written to the storage system. In particular, at the time when the file system allocates storage, such as when creating a file or performing an extending write (append) operation, allocating storage to an unallocated region of a sparse file, defragmenting a file, and the like, a storage system can verify that actual physical storage capacity is available. Thus, if there is insufficient actual physical capacity at the time when a storage allocation is attempted, then an error message can be sent and remedial action can be taken.

Abstract: An extensible file system format for portable storage media is provided. The extensible file system format includes the specification of primary and secondary directory entry types that may be custom defined. The primary and secondary directory entry types can be further classified as critical and benign directory entries. The directory entry types can define whether a cluster chain corresponding to a file can be contiguously allocated.

Abstract: A file system which is enabled to use a Metadata Partition instead of VAT for write-once discs, is provided by a pseudo-overwrite method. On applying this invention to a drive apparatus which supports pseudo-overwrite media, the file system distinguishes data to overwrite from data to append. When the data is newly written to a logical sector (S1305), the drive apparatus writes the data to a physical sector to which the logical sector corresponds (S1311). When the logical sector is overwritten the data is written to another unrecorded physical sector in the volume space (1321), and remapping information that specifies the original address, and the remapping address are stored in the remapping table (S1322).

Abstract: File system metadata regarding states of a file system affected by transactions is tracked consistently even in the face of dirty shutdowns which might cause rollbacks in transactions which have already been reflected in the metadata. In order to only request time- and resource-heavy rebuilding of metadata for metadata which may have been affected by rollbacks, reliability information is tracked regarding metadata items. When a metadata item is affected by a transaction which may not complete properly in the case of a problematic shutdown or other event, that metadata item's reliability information indicates that it may not be reliable in case of such a problematic (“dirty” or“abnormal”) event. In addition to flag information indicating unreliability, timestamp information tracking a time of the command which has made a metadata item unreliable is also maintained.

Abstract: Described is a storage reports scanner that works to generate reports of storage usage in computer systems in an efficient manner. The scanner receives a set of namespaces for a file system volume from a storage reports engine. The scanner scans file system metadata to construct a directory table of entries corresponding to a directory tree of nodes representative of the hierarchy of directories of the file system volume. Each node corresponding to a namespace in the namespace set is marked as included. A second scan of the file system metadata determines, for each file, whether that file is in or under an included directory by accessing the directory table. For each file that is in or is under an included directory, file information is returned to the engine. The engine may request the scanner to provide full path information, which the scanner determines via the directory table.

Abstract: To reconstitute a ghosted file for use, a single ghosting filter on a computing device locates ghosting information in the metadata of the ghosted file and locates within the ghosting information an identification of a particular ghosting manager of the computing device, where the identified ghosting manager is responsible for the ghosted file. Thereafter, the ghosting filter communicates to the identified ghosting manager a request to obtain data of the ghosted file from a corresponding alternate location, and the identified ghosting manager does in fact obtain such requested data from such alternate location. Upon receiving the requested data of the ghosted file from the identified ghosting manager, then, the ghosting filter reconstitutes the received data to the ghosted file. The single ghosting filter is generic to all of the ghosting managers of the computing device.

Abstract: A ghosting filter on a computing device receives a read command for a requested range of data of a ghosted file. The requested range is categorized into first segments present in the ghosted file, second segments pending to be reconstituted from an alternate location to the ghosted file, and third segments that are not first or second segments. Reconstitution of any third segments is initiated to convert same to second, pending segments, and the read command is responded to with the requested range of the data once all second segments are in fact reconstituted from the alternate location to the ghosted file and thus converted to first, pending segments.

Abstract: A computing device has a file stored on a storage volume by a file system and accessed through such file system. The file is defined to include data and metadata relating to the data, and at least a portion of the data of the file is removed from the file and stored at an alternate location such that the data does not occupy substantially any space on the volume and the file is in a reduced, ghosted form. The ghosted file is reconstituted for use by retrieving the data from the alternate location and associating such retrieved data with such ghosted file to form the reconstituted file.

Abstract: Files on a computing device are defined to include data and metadata relating to the data. Data from each file has been removed therefrom and stored at an alternate location and the file is in a reduced, ghosted form. Each of at least some ghosted files has been fully or partially reconstituted for use by retrieving the data thereof from the alternate location and associating such retrieved data with such ghosted file to form the reconstituted file. Upon receiving a trigger based on a triggering event, files are selected from among the fully and partially reconstituted files and never-ghosted files based on first predetermined selection criteria, and each of at least some of the selected files are re-ghosted.

Abstract: A computing device has a storage volume, a file system managing the storage volume, and a file stored on the storage volume and accessed by such file system. The file system receives an open command for the file from an application, notes that the file has been ghosted in that data of the file has been moved to an alternate location, and returns an error. The returned error is intercepted and the file system is commanded to retrieve ghosting information from the ghosted file. A handle corresponding to the ghosted file is delivered to the application, and a read command for the file is received from the application, including the handle, an offset, and a read length. Reconstituting of the ghosted file is initiated based on the data thereof at the alternate location, and after reconstituting the read command is responded to with the data requested.

Abstract: A ghosting filter on a computing device perceives that a file is in a ghosted form and commands a file system of the device to retrieve ghosting information from the ghosted file. The ghosting filter receives a read command from an application on the device with respect to a portion of the data of the ghosted file. The read command has parameters including an offset into the portion of the data and a read length with respect to such portion. The ghosting filter initiates reconstituting of the portion of the data of the ghosted file based on the received ghosting information and data of the ghosted file at an alternate location, and after the portion of the data of the ghosted file has been reconstituted responds to the read command with the portion of the data requested.

Abstract: An extensible file system format for portable storage media is provided. The extensible file system format includes the specification of primary and secondary directory entry types that may be custom defined. The primary and secondary directory entry types can be further classified as critical and benign directory entries.

Abstract: A method and system for maintaining namespace consistency between selected objects maintained by a file system and a filter associated therewith. A filter monitors selected types of requests (or operations associated therewith) and determines whether the object is within a namespace associated with the filter. The namespace associated with the filter is updated based on a change to the object.