Abstract: A driver, e.g., a UEFI driver (140), for a device (120) in a host (110) starts before an OS boot. The driver (140) provides functions including gathering information regarding the host system (110), directing the device (120) to transmit the gathered information to a cloud-based service (182), directing the device (120) to provide a catalog of current firmware, updating firmware in the host (110) or device (120) based on the catalog, and configuring the device (120). The device may be a storage processing unit (120) that is part of a cluster (100) that presents virtual volumes including a boot volume (138) for the host (110), and execution of the driver (140) can provide a delay until a boot volume (138) is ready.

Abstract: A storage system (100) stores metadata using an append log to provide speed and reliability. Appending entities to the end of a metadata store (154) and provides reliability in the event of failure because a failed append operation at worst corrupts the end of the append log, which is easily detected and corrected. A metadata store (154) can be split into sections (158). A used section (158) may be identified as garbage when the stored metadata in other sections (158) make the all of its stored entity sets stale. A used section (158) can be made garbage by storing the entity sets from the section (158) in another section (158). Sections (158) containing garbage thereby change to unused allow replacement and removal of previous sections (158) of metadata.

Abstract: A storage platform (100) with cloud-based management (182) creates and provisions a boot volume (138) for a server (110) in the storage platform (100) during system setup. A storage template (410) defines characteristics of the boot volume and provides a URL to an OS image (166 or 186) that a service processing unit (120) can use, without any further actions from the user, to populate the boot volume (138).

Abstract: Configuring, distributing, and managing virtual volumes in a storage system are automated and simplified so that administrators may be relieved of such tasks and non-storage administrators can make use of the storage technology. A cloud-based storage management infrastructure (180) can perform the automated process and may employ templates (186) that define necessary information and processes regarding how service processing units (120) are clustered in a storage platform (100), volume distribution of virtual volumes (132, 134, 138), volume properties, and presentation to servers (110), considering operating system and application requirements.

Abstract: A manufacturer (120) of a device (140) uses a tester image (134) from a cloud service (130) when configuring test equipment (150) for testing of a device (140) being manufactured, and the device (140) contacts the cloud service (130) and installs firmware or software (146) based on a device image (132). A vendor or developer (110) can change or update the images (132, 134) to update a manufacturing process without needing the manufacturer (120) to have special training or knowledge. Further, the cloud service (130) can receive test results from the manufacturer (120) and may record access to image (132), enabling the vendor (110) to monitor manufacturing of the device (140).

Abstract: A resynchronization operation (300) adapts according to activity histories (148) within a storage platform (100). An owner node (A) and a backup storage node (B) may track activity such as the IO operations begun and use recent activity to determine respective amounts of data the owner (A) and backup (B) can expect to process without unacceptably degrading storage services. The owner (A) transfer resynchronization data in chunks, each having a size limited by the current amounts the owner (A) and backup (B) determined from current activity. When activity is low or idle, large chunks may be sent to quickly complete resynchronization, while a busy system uses smaller chunks such that the system performance is not adversely affected.

Abstract: Storage redundancy may be resynchronized without determining a snapshot difference. A storage component (210) owning a volume (122) can maintain current and expected generation numbers (212, 214) based on modification requests received and modification requests that a backup component (220) acknowledges completing. The backup (220) can maintain current and expected generation numbers (222, 224) based on modification requests received and applied to a backup volume (124). If either component (210, 220) fails and later returns to service, differences between the owner's current and expected generation numbers (212, 214) and the backup's current and expected generation numbers (222, 224) indicate which modification requests may have been missed and need to be reconstructed to restore synchronization.

Abstract: A storage processing unit (SPU), which may be resident in a server in a storage system, provides a boot volume to the server and provides storage services. The SPU may execute a process including taking three snapshots of the boot volume respectively after writing an operating system image into the boot volume, after writing component images or otherwise customizing contents of the boot volume, and after the server boots from the boot volume. For updates, stability, or recovery of the storage system, the SPU may promote any of the snapshots to be the boot volume before the server reboots.

Abstract: A cluster storage system including servers containing storage processing units (SPUs) can create synchronized snapshot sets for the volumes that the SPUs maintain and can report the snapshot sets to a cloud-based service. Each snapshot in a set reflects the state a corresponding volume had at a rollback point corresponding to the set. A user of the storage system contacts the cloud-based service about recovery of the storage system, and the cloud-based service may present the user with a list of rollback points corresponding to the synchronized snapshot sets. The user may select to recover the storage system to any of the rollback points, and the SPUs promote the selected snapshots to replace the volumes for storage services.

Abstract: A cluster storage system takes snapshots that are consistent across all storage nodes. The storage system can nearly instantaneously promote a set of consistent snapshots to their respective base volumes to restore the base volumes to be the same as the snapshots. Given these two capabilities, users can restore the system to a recovery point of the user's choice, by turning off storage service I/O, promoting the snapshots constituting the recovery point, rebooting their servers, and resuming storage service I/O.

Abstract: A storage system sends information on input/output patterns and data blocks written to a cloud-based service for detection of suspected ransomware activity. Analysis of the I/O patterns and data may be performed by the storage system, the cloud-based service, or both. The cloud-based service can instruct the storage system to create or maintain snapshots that allow the storage system continue operation and allow the storage system to roll back for recovery after a ransomware attack is confirmed.

Abstract: A method for a storage system to process input and output operations. The method includes receiving writes over time to an address at a base virtual volume, storing each of the writes in a physical storage at a new location that is without existing data, tagging each stored write with a different generation number to distinguish between different versions of data written to the address at the base virtual volume, receiving a read of the address at the base virtual volume, and, in response to the read of the address at the base virtual volume, returning one of the stored writes that is tagged with a newer generation number than a remainder of the stored writes.

Abstract: Storage processing units or SPUs (120) operate backend storage (150) to provide scalable storage services, redundancy, and disaster recovery to an enterprise. Each SPU (120) may reside in a host server (110) and may include an processor domain (490) with backup power (440) and isolation from a host domain (480) to allow the SPU (120) to operate after the host (110) fails or otherwise stops providing power. A cloud-based management system (180) may assess the storage needs of the enterprise, identify a storage style suited to the enterprise, and direct the SPUs (120) to create virtual volumes (122, 124, 128) having characteristics according to the storage style identified. The cloud based management system (180) may eliminate the need for the enterprise to have expertise in storage management.

Abstract: A storage system (100) stores metadata using an append log to provide speed and reliability. Appending entities to the end of a metadata store (154) and provides reliability in the event of failure because a failed append operation at worst corrupts the end of the append log, which is easily detected and corrected. A metadata store (154) can be split into sections (158). A used section (158) may be identified as garbage when the stored metadata in other sections (158) make the all of its stored entity sets stale. A used section (158) can be made garbage by storing the entity sets from the section (158) in another section (158). Sections (158) containing garbage thereby change to unused allow replacement and removal of previous sections (158) of metadata.

Abstract: Storage redundancy may be resynchronized without determining a snapshot difference. A storage component (210) owning a volume (122) can maintain current and expected generation numbers (212, 214) based on modification requests received and modification requests that a backup component (220) acknowledges completing. The backup (220) can maintain current and expected generation numbers (222, 224) based on modification requests received and applied to a backup volume (124). If either component (210, 220) fails and later returns to service, differences between the owner's current and expected generation numbers (212, 214) and the backup's current and expected generation numbers (222, 224) indicate which modification requests may have been missed and need to be reconstructed to restore synchronization.

Abstract: A storage system (400) includes a storage processor (420-1) such as a storage card resident in a host server (410-1) and coupled to the storage device (450-1). The storage processor (420-1) may be configured to create a virtual volume (428-1), store content derived from an image (492) downloaded from a URL storage corresponding to the virtual volume (428-1), and present the virtual volume (428-1) to the host server as a boot LUN. A management infrastructure (480) can be used to create a library (490) of images (492, 494) corresponding to different storage system characteristics and used to selected which URL is provided to the storage processor (420-1).

Abstract: An initiating node (C) in a storage platform (100) receives a modification request (312, 314) for changing an object (O). The initiating node (C), using system configuration information (127), identifies an owner node (A) and a backup node (B) for the object (O) and sends change data (324, 334) to the owner node (A) and the backup node (B). The owner node (A) modifies the object (O) with the data (324) from the initiating node (C) and sends an update request (352) that does not include the data (324) to the backup node (B). The backup node (B) modifies a backup object (O?) with data (334) from the initiating node (C).

Abstract: A resynchronization operation (300) adapts according to activity histories (148) within a storage platform (100). An owner node (A) and a backup storage node (B) may track activity such as the IO operations begun and use recent activity to determine respective amounts of data the owner (A) and backup (B) can expect to process without unacceptably degrading storage services. The owner (A) transfer resynchronization data in chunks, each having a size limited by the current amounts the owner (A) and backup (B) determined from current activity. When activity is low or idle, large chunks may be sent to quickly complete resynchronization, while a busy system uses smaller chunks such that the system performance is not adversely affected.

Abstract: In some examples, sectors of a solid-state drive are unmapped to initialize the sectors. The sectors include a data portion and a protection portion. When an unmapped sector is read, the solid-state drive can return a pre-set value for the unmapped sector, where the pre-set value includes a known fixed value to represent the protection portion of the unmapped sector. The storage controller is to recognize the known fixed value returned by the solid-state drive responsive to the read as representing the unmapped sector as being initialized, but not written to.

Abstract: A technique includes changing a configuration setting of a virtual volume of data stored in a storage system. The technique includes converting data of the virtual volume in place to reflect the changing of the configuration setting.