Abstract: A block I/O request processing threads executes only on a processor core to which it is assigned. After it executes for a period of time, the block I/O request processing thread yields its assigned processing core to another type of thread that is runnable on the processing core, such as a file I/O request processing thread. When there are no block I/O requests for a block I/O request processing thread to process, it is suspended from being executed. A monitor thread running on another processing core detects that a newly received block I/O request is available for processing, and makes the block I/O request processing thread runnable again. The block I/O request processing thread may be assigned a higher priority than file I/O request processing threads, and preempt any runnable file I/O request processing threads when it is made runnable to process the newly received block I/O request.

Abstract: Techniques are presented for dynamically allocating memory between containers.

Abstract: A data processing system backs up snapshots of storage objects to cloud storage by identifying to a cloud gateway a set of snapshots to be archived, and making the set available to the cloud gateway. Upon request by the cloud gateway, snapshot metadata is provided that includes offsets and lengths of data extents of the set of snapshots. On further request of the cloud gateway using the metadata, the data extents of the set of snapshots are provided to the cloud gateway, which uses the extents to create corresponding objects and stores the objects in the cloud storage, each object including the data extents and the snapshot metadata for a respective snapshot. Backup and restore are initiated by the gateway or by the data storage system in different embodiments.

Abstract: Archiving local logical units of data storage (LUNs) to cloud storage, wherein the local LUNs reside on local physical storage of a data storage system, includes establishing a mirror between a local LUN and a cloud-backed LUN backed by cloud physical storage of a cloud storage system, the mirror making data contents of the cloud-backed LUN identical to data contents of the local LUN. Once the mirror is established, then (a) a stub is deposited on the local LUN to direct subsequent IOs to the cloud-backed LUN, and (b) local physical storage of the local LUN is released for allocation to other local LUNs. Subsequent IOs to the local LUN are satisfied from the cloud-backed LUN. An archived LUN can be restored by a restore process.

Abstract: A method, computer program product, and computing system for storing a plurality of identifiers on a local data storage system. The plurality of identifiers locate a plurality of archived files at a plurality of defined remote addresses on a remote data storage system. The deletion of at least one of the plurality of identifiers is sensed, thus defining at least one deleted identifier. Temporal information of the at least one deleted identifier is compared to temporal information for a data protection operation performed on at least a portion of the local data storage system.

Abstract: A method, computer program product, and computing system for locally processing a plurality of data files stored on a local data storage system to effectuate the storage of one or more archivable files at one or more defined remote addresses on a remote data storage system. One or more identifiers, that locate the one or more archivable files at the one or more defined remote addresses on the remote data storage system, are stored on the local data storage system. A local database, that defines the one or more identifiers, is maintained on the local data storage system.

Abstract: A method, computer program product, and computing system for locally processing a plurality of data files stored on a local data storage system to identify an archivable file for storage on a remote data storage system. A remote tiering appliance is enabled to obtain the archivable file, wherein the remote tiering appliance stores the archivable file at a defined remote address on the remote data storage system. An identifier is received from the remote tiering appliance that locates the archivable file at the defined remote address on the remote data storage system. The identifier is stored on the local data storage system.

Abstract: A distributed object store in a network storage system uses location-independent global object identifiers (IDs) for stored data objects. The global object ID enables a data object to be seamlessly moved from one location to another without affecting clients of the storage system, i.e., “transparent migration”. The global object ID can be part of a multilevel object handle, which also can include a location ID indicating the specific location at which the data object is stored, and a policy ID identifying a set of data management policies associated with the data object. The policy ID may be associated with the data object by a client of the storage system, for example when the client creates the object, thus allowing “inline” policy management. An object location subsystem (OLS) can be used to locate an object when a client request does not contain a valid location ID for the object.

Abstract: Archiving local logical units of data storage (LUNs) to cloud storage, wherein the local LUNs reside on local physical storage of a data storage system, includes establishing a mirror between a local LUN and a cloud-backed LUN backed by cloud physical storage of a cloud storage system, the mirror making data contents of the cloud-backed LUN identical to data contents of the local LUN. Once the mirror is established, then (a) a stub is deposited on the local LUN to direct subsequent IOs to the cloud-backed LUN, and (b) local physical storage of the local LUN is released for allocation to other local LUNs. Subsequent IOs to the local LUN are satisfied from the cloud-backed LUN. An archived LUN can be restored by a restore process.

Abstract: Shipping local snapshots of logical units of data storage (LUNs) to cloud storage, wherein the local snapshots reside on local physical storage of a data storage system, includes replicating a baseline local snapshot of a LUN to a cloud-backed LUN backed by cloud physical storage of cloud storage system, and taking a first snapshot of the cloud-backed LUN to establish a baseline cloud-backed snapshot. For a subsequent local snapshot of the LUN, the method (1) identifies data content differences between the subsequent local snapshot and the baseline local snapshot, (2) updates the cloud-backed LUN by applying the data content differences, and (3) takes a second snapshot of the cloud-backed LUN, the second snapshot being a cloud-backed copy of the subsequent local snapshot and containing, in the cloud physical storage, (a) first blocks unique to the second snapshot and (b) second blocks shared with the baseline cloud-backed snapshot.

Abstract: A technique for managing cloud storage provides a unified framework that supports both block-type data, such as LUNs (Logical UNits) and volumes, and file-type data, such as files, and expresses both types of data in the form of objects, which form a common base for both types of data. The framework includes a single API (application program interface) for managing storage and retrieval of block-derived objects and file-derived objects from the cloud, e.g., from a cloud-based data store.

Abstract: A system and method can monitor one or more user sessions on a target system in a computing environment. An account managing system can capture a plurality of user session screen captures that are associated with said one or more user sessions on the target system. Furthermore, the account managing system can compare a user session screen capture, which is captured at a time during said one or more user sessions, with one or more user session screen captures that are recorded before the time. Then, the account managing system can record said user session screen capture if the target system is determined to be active at the time when said user session screen capture is captured.

Abstract: A technique for operating a Hyper-Converged Infrastructure (HCI) system includes running an IO stack on a physical computing server of the HCI system. The IO stack exposes multiple protocol endpoints for providing host applications with access to data objects. Protocol endpoints are exposed both to host applications running within the HCI system and to host applications running on external computing devices, thus enabling the HCI system to double as a data storage system with respect to external computing devices.

Abstract: A method of writing data to persistent storage includes (a) for each data block of a set of data blocks, storing data of that data block at an offset within a log segment of the persistent storage in conjunction with a logical block address (LBA) of that data block on the persistent storage, a size of the log segment being larger than a size of each data block, (b) identifying a particular log segment of the persistent storage that has become filled with data blocks, and (c) upon identifying the particular log segment as having become filled, inserting pointers to respective data blocks stored within the particular log segment into respective locations defined by the respective LBA of each respective data block within a map tree.

Abstract: A hyper-converged infrastructure (HCI) provides one or more HCI units, each HCI unit including a pair of physical computing servers coupled to shared, nonvolatile storage. The shared, nonvolatile storage of each HCI unit is dedicated to that pair of physical computing servers and provides redundant storage of application data. Each of the pair of physical computing servers runs a set of application instances and an IO (Input/Output) stack. The application instances receive client requests over a network and generate IO requests specifying reads and writes of application data. The IO stack processes the IO requests to effect the specified reads and writes in the shared non-volatile storage.

Abstract: A data storage system has one or more processing nodes, each processing node comprising memory coupled to processing circuitry, the one or more processing nodes running a set of virtualized filesystem managers (VFMs) having a shared namespace. The set of VFMs includes (a) a master VFM for managing a configuration filesystem stored on the persistent storage, the configuration filesystem storing configuration information for the set of VFMs and (b) a slave VFM for remotely mounting the configuration filesystem from the master VFM, the slave VFM obtaining details of its configuration from the remotely-mounted configuration filesystem, the slave VFM sharing the shared namespace with the set of VFMs, the shared namespace including a set of filesystems, each filesystem of the shared namespace being managed by a single VFM, and each filesystem of the shared namespace being accessible by the remote host through any of the VFMs of the set of VFMs.

Abstract: A distributed object store in a network storage system uses location-independent global object identifiers (IDs) for stored data objects. The global object ID enables a data object to be seamlessly moved from one location to another without affecting clients of the storage system, i.e., “transparent migration”. The global object ID can be part of a multilevel object handle, which also can include a location ID indicating the specific location at which the data object is stored, and a policy ID identifying a set of data management policies associated with the data object. The policy ID may be associated with the data object by a client of the storage system, for example when the client creates the object, thus allowing “inline” policy management. An object location subsystem (OLS) can be used to locate an object when a client request does not contain a valid location ID for the object.

Abstract: A distributed object store in a network storage system uses location-independent global object identifiers (IDs) for stored data objects. The global object ID enables a data object to be seamlessly moved from one location to another without affecting clients of the storage system, i.e., “transparent migration”. The global object ID can be part of a multilevel object handle, which also can include a location ID indicating the specific location at which the data object is stored, and a policy ID identifying a set of data management policies associated with the data object. The policy ID may be associated with the data object by a client of the storage system, for example when the client creates the object, thus allowing “inline” policy management. An object location subsystem (OLS) can be used to locate an object when a client request does not contain a valid location ID for the object.

Abstract: A distributed object store in a network storage system uses location-independent global object identifiers (IDs) for stored data objects. The global object ID enables a data object to be seamlessly moved from one location to another without affecting clients of the storage system, i.e., “transparent migration”. The global object ID can be part of a multilevel object handle, which also can include a location ID indicating the specific location at which the data object is stored, and a policy ID identifying a set of data management policies associated with the data object. The policy ID may be associated with the data object by a client of the storage system, for example when the client creates the object, thus allowing “inline” policy management. An object location subsystem (OLS) can be used to locate an object when a client request does not contain a valid location ID for the object.

Abstract: A system and method can monitor one or more user sessions on a target system in a computing environment. An account managing system can capture a plurality of user session screen captures that are associated with said one or more user sessions on the target system. Furthermore, the account managing system can compare a user session screen capture, which is captured at a time during said one or more user sessions, with one or more user session screen captures that are recorded before the time. Then, the account managing system can record said user session screen capture if the target system is determined to be active at the time when said user session screen capture is captured.