Abstract: A technique for data sharing among multiple filers that share a volume in a private or public cloud object store is implemented. In this approach, a mechanism is provided to enable a local filer to determine whether other filers that are sharing the volume have a consistent view of new data being written to the cloud object store by the local filer. The begins by associating together a collection of one or more files in a “push class.” On demand, a push operation for the push class is initiated on the local filer. Preferably, the push is managed according to one or more push criteria associated with the push class. Typically, the push operation pushes file data and metadata associated with the one or more files of the push class in respective phases, with the file data being pushed to the cloud during a first phase and the metadata associated with that file data being pushed during a second phase that follows the first phase.

Abstract: A cloud-native global file system is augmented to include a file exporter (or, more generally, a file export tool) that facilitates an enterprise customer's use of a cloud-native tool that would otherwise be unable to operate against the global file system's underlying file system representation. In a typical use case, the file exporter is configured to extract in a native object format and to an unencrypted target all or a portion of a volume's data from the underlying file system representation. In this manner, the exporter creates a copy of the data set that the enterprise user can then leverage against the desired cloud-native tool or other cloud services that are not under the management or control of the global file system service provider.

Abstract: A versioned file system comprising network accessible storage is provided. Aspects of the system include globally locking files or groups of files so as to better control the stored files in the file system and to avoid problems associated with simultaneous remote access or conflicting multiple access requests for the same files. A method for operating, creating and using the global locks is also disclosed. A multiprotocol global lock can be provided for filing nodes that have multiple network protocols for generating local lock requests.

Abstract: A cloud native global file system is augmented to include a “file accelerator” that is configured to speed up data propagation with respect to updates on a shared volume and, in particular by performing real-time analysis on audit event data to coordinate pushes and pulls across multiple edge appliances, effectively replacing static snapshot and synchronization schedules. A “push” refers to a snapshot on the volume that occurs at a particular filer, and a “pull” refers to a synchronization (sync) operation initiated by a particular filer to obtain whatever is in the cloud (and that is the subject of the pull). The file accelerator operates in several modes of “triggered” operation based on user activity, and under the control of a cloud-based controller.

Abstract: A cloud-native global file system in which a local filer creates objects and forward them to a cloud-based object store is augmented to include constant-time rekeying (CTR). At volume creation time on the filer, a random Intermediate Key (IK) is generated. The IK is encrypted using one or more public key(s) for the volume in question, and then stored in encrypted form in a volume metadata file (e.g., cloudvolume.xml) alongside the other volume information. Once created, the IK is treated like any other volume metadata. During startup of a volume manager on the filer, the one or more per-volume IK blobs (present) are decrypted using an appropriate secret key, and then cached in memory. All objects sent to the cloud are then symmetrically encrypted to the current IK for that volume. All objects read from the cloud are decrypted using the locally-cached IK.

Abstract: A cloud-based write-once object store is configured to store inode-based data exported to the store from an enterprise file system. For each version of data (e.g., a file) exported to the store, there is a version of the inode corresponding to that data. As versions of the data are exported to the cloud, the system creates multiple versions of the inode. The set of inode versions corresponding to the versions of the file have a pointer associated therewith that specifies the latest version of the data associated with the inode. The inode versions in the set share the same pointer. The inode versions represent a revision history for the inode. For each inode version corresponding to a version of the data, information is received and stored in a new portion of the object store. The inode version for a file version comprises a list of data chunks for the file.

Abstract: A cloud-native global file system, in which one or more filers are associated with a volume of a versioned files system in a private, public or hybrid cloud object store, is augmented to include a rapid ransomware recovery service. Upon detecting a ransomware attack associated with one or more files or directories of the volume, read and write access to the volume is restricted. A recovery filer is then activated or designated in the cloud. A restore operation is then initiated at the recovery filter. Following completion of the restore operation, a new clean (healthy) snapshot of the volume is then created using the recovery filer For any filer other than the recovery filer, a determination is made whether the filer has completed a merge operation with respect to the new clean snapshot. If so, read and write access to the volume is re-enabled from that filer.

Abstract: A cloud-native global file system used to provide primary file storage for enterprise data is augmented to provide “direct-to-cloud” (D2C) migration of an initial data set. In addition to providing a filer, the service provider configures a direct-to-cloud migration tool, typically as a downloadable virtual machine (VM), that is executed in association with the hardware of the enterprise filesystem whose data set is being migrated. The migration tool reads the existing filesystem, transforms the data into a format consistent with that done by a filer, and pushes the result (a single version) directly to an object store in the cloud. In a first pass (run), typically a large bulk of the data is moved and, depending on how the migration tool is configured, one or more additional passes may then be carried out. When migration is complete (or substantially complete), the filer then is activated to complete the migration (if need be) and take over the go-forward operations.

Abstract: A cloud-native global file system is augmented to include a file exporter (or, more generally, a file export tool) that facilitates an enterprise customer's use of a cloud-native tool that would otherwise be unable to operate against the global file system's underlying file system representation. In a typical use case, the file exporter is configured to extract in a native object format and to an unencrypted target (e.g., an S3 bucket, an Azure storage account, and the like) all or a portion of a volume's data from the underlying file system representation. In this manner, the exporter creates a copy of the data set that the enterprise user can then leverage against the desired cloud-native tool or other cloud services that are not under the management or control of the global file system service provider.

Abstract: A versioned file system comprises a set of structured data representations. At a first time, an interface creates and exports to a cloud data store a first structured data representation corresponding to a first version of the local file system. The first structured data representation is an XML tree having a root element, one or more directory elements associated with the root element, and one or more file elements associated with a given directory element. Upon a change within the file system, the interface creates and exports a second structured data representation corresponding to a second version of the file system. The second structured data representation differs from the first structured data representation up to and including the root element of the second structured data representation. The interface continues to generate and export the structured data representations to the data store.

Abstract: A versioned file storage system (VFS) and method for operating and using the same is disclosed. In an aspect, a mechanism is provided wherein a first VFS interface unit coupling the VFS to a local data storage system is replaced with a second VFS interface unit in a coordinated procedure for taking the first unit offline, making a reliable snapshot of its data and cache structure in the VFS, and loading the same data and cache structure into the second VFS interface brought online. The first and second VFS interfaces transfer the necessary data to achieve the switch through respective side-loading daemons running in each interface. Clients in the local data storage system experience minimal interruption of services in the VFS.

Abstract: A technique for data sharing among multiple filers that share a volume in a private or public cloud object store is implemented. In this approach, a mechanism is provided to enable a local filer to determine whether other filers that are sharing the volume have a consistent view of new data being written to the cloud object store by the local filer. The begins by associating together a collection of one or more files in a “push class.” On demand, a push operation for the push class is initiated on the local filer. Preferably, the push is managed according to one or more push criteria associated with the push class. Typically, the push operation pushes file data and metadata associated with the one or more files of the push class in respective phases, with the file data being pushed to the cloud during a first phase and the metadata associated with that file data being pushed during a second phase that follows the first phase.

Abstract: An interface between an existing local file system and a data store generates and exports to the data store a versioned file system. The state of the local file system at a given point in time can be determined using the versioned file system. In operation, the interface creates and exports to the data store structured data representations, which correspond to versions of the local file system, as well as actual file system data that these structured data representations represent. A cache associated with the interface stores recently used data and metadata, as well as all write data and metadata waiting to be transferred to the data store. Prior to transfer, one or more data transformations may be applied to the data and metadata. In one embodiment, the data store comprises one or more cloud storage service providers. A content control system is used to configure and manage the interface.

Abstract: A cloud-native global file system in which a local filer creates objects and forward them to a cloud-based object store is augmented to include a reshapable caching scheme for the local filer. Like striped caches, the approach uses a stripe, but the striping is implemented via a true RAID 0 (disk striping) rather than as a striped LV (logical volume) device. This approach allows for a “reshape” operation to convert from a n-way stripe set to a n+1-way stripe set. Preferably, a reshape involves redistributing each block on disk to its new calculated home. For example, going from a single disk to a two disk set would move every other block from disk 1 to disk 2, and rearrange the blocks on disk 1 to fill in the “holes”. Performance after the reshape matches that of a striped cache. In one embodiment, the cache is structured as a “degraded” RAID 4.

Abstract: An operations server synchronizes updates to a cloud-based shared versioned file system. The shared versioned file system includes directories and sub-directories that are divided into shards. The operations server coordinates requests from local filer servers, each running a respective local version of the shared versioned file system, to update a shard in the cloud-based shared versioned file system. The operations server can provide a global lock on the shard to a local filer server before it updates the shard in the cloud-based shared versioned file system.

Abstract: A cloud-native global file system, in which one or more filers are associated with a volume of a versioned files system in a private, public or hybrid cloud object store, is augmented to include a rapid ransomware recovery service. Upon detecting a ransomware attack associated with one or more files or directories of the volume, read and write access to the volume is restricted. A recovery filer is then activated or designated in the cloud. A restore operation is then initiated at the recovery filter. Following completion of the restore operation, a new clean (healthy) snapshot of the volume is then created using the recovery filer For any filer other than the recovery filer, a determination is made whether the filer has completed a merge operation with respect to the new clean snapshot. If so, read and write access to the volume is re-enabled from that filer.

Abstract: A versioned file system comprising network accessible storage is provided. Aspects of the system include globally locking files or groups of files so as to better control the stored files in the file system and to avoid problems associated with simultaneous remote access or conflicting multiple access requests for the same files. A method for operating, creating and using the global locks is also disclosed. A multiprotocol global lock can be provided for filing nodes that have multiple network protocols for generating local lock requests.

Abstract: A system and method of managing object data stored in a heterogeneous cloud environment comprises a separate cloud management system disposed such that the communications path between a user and each cloud to which the user has access is a different communications path than that between the user and the cloud management system or the cloud management system and each of the clouds.

Abstract: A cloud-native global file system is augmented to include a file exporter (or, more generally, a file export tool) that facilitates an enterprise customer's use of a cloud-native tool that would otherwise be unable to operate against the global file system's underlying file system representation. In a typical use case, the file exporter is configured to extract in a native object format and to an unencrypted target (e.g., an S3 bucket, an Azure storage account, and the like) all or a portion of a volume's data from the underlying file system representation. In this manner, the exporter creates a copy of the data set that the enterprise user can then leverage against the desired cloud-native tool or other cloud services that are not under the management or control of the global file system service provider.

Abstract: An operations server synchronizes updates to a cloud-based shared versioned file system. The shared versioned file system includes directories and sub-directories that are divided into shards. The operations server coordinates requests from local filer servers, each running a respective local version of the shared versioned file system, to update a shard in the cloud-based shared versioned file system. The operations server can provide a global lock on the shard to a local filer server before it updates the shard in the cloud-based shared versioned file system. Preferably, shards are sized dynamically based on the number of entries in the directories associated therewith.