Dell Products Inc.

Emc IP Holding Company LLC

Lixin Pang

Rong Yu

Peng Wu

Jiahui Wang

Shao Hu

Ramesh Doddaiah

Mohammed Asher

Mohammed Asher Vt

One or more aspects of the present disclosure relate to distributing write destaging amongst a storage array's boards. In embodiments, an input/output (IO) workload is received at a storage array. In addition, a write IO request in the IO workload is directed to a target board of a plurality of boards of the storage array based on one or more performance-related hyperparameters of each board. Further, write data of the write IO request to a storage device is destaged by the target board.

Distributed write destaging

As front-end write IO operations occur, the front-end write IO operations are allocated slots of global memory and mapped to slices of back-end tracks. A back-end write destage manager allocates back-end slices to aging buckets based on the number of write operations pending destage for the given back-end slice. As global memory destage pressure increases, the back-end write destage manager uses a weighted bucket table to increase the weight back-end slices with larger numbers of front-end tracks that are occupying the larger slots of global memory. This results in back-end slices that are owed data from front-end tracks occupying larger front-end slot sizes to be placed in aging buckets with shorter aging times. These back-end slices are thus more quickly selected to be destaged, thus causing a larger percentage global memory slots of the largest slot size to be made available to be allocated to subsequent host IO write operations.

Global memory slot size based destage prioritization

One or more aspects of the present disclosure relate to performant destaging of write pending (WP) data to disk. In embodiments, an input/output (IO) workload is received at a storage array. Additionally, the IO workload can include an IO request with a random write request. Further, a write destage context for write-pending (WP) data corresponding to the random write request can be generated by a data services engine of the storage array. In addition, using the write destage context, a disk adapter (DA), at a backend of the storage array, is enabled to destage write-pending (WP) data without reading from a target write location of the random write request on a storage device on the storage array.

Performant write pending data destaging

In a storage system where Front-End (FE) tracks do not correspond to Back-End (BE) tracks on a one-to-one basis, a Logical Entry (LE) table is implemented in the BE processes to enable masking to occur on BE Logical Entry values rather than on BE tracks. An LE watch table is used to correlate LE values with BE tracks. When a RAID slice destage is initiated to move data from the FE tracks to BE tracks implementing the RAID slice, the LE watch table is used to identify a respective set of LE values that correspond to each respective RAID slice BE track. Entries of the BE mask corresponding to the LE values identified from the LE watch table are used to identify FE tracks that contain data to be included in the RAID slice destage. Metadata is retrieved for each identified FE track, and the RAID slice destage is implemented.

Logical back-end device entry-based slice write destage

A synchronous destage process is used to move data from shared global memory to back-end storage resources. The synchronous destage process is implemented using a client-server model between a data service layer (client) and back-end disk array of a storage system (server). The data service layer initiates a synchronous destage operation by requesting that the back-end disk array move data from one or more slots of global memory to back-end storage resources. The back-end disk array services the request and notifies the data service layer of the status of the destage operation, e.g. a destage success or destage failure. If the destage operation is a success, the data service layer updates metadata to identify the location of the data on back-end storage resources. If the destage operation is not successful, the data service layer re-initiates the destage process by issuing a subsequent destage request to the back-end disk array.

Synchronous destage of write data from shared global memory to back-end storage resources

A data service layer running on a storage director node generates a request to destage host data from a plurality of cache slots in a single back-end track. The destage request includes pointers to addresses of the cache slots and indicates an order in which the host application data in the cache slots is to be included in the back-end track. A back-end redundant array of independent drives (RAID) subsystem running on a drive adapter is responsive to the request to calculate parity information using the host application data in the cache slots. The back-end RAID subsystem assembles the single back-end track comprising the host application data from the plurality of cache slots of the request, and destages the single back-end track to a non-volatile drive in a single back-end input-output (IO) operation.

Destaging multiple cache slots in a single back-end track in a RAID subsystem

A storage system that supports multiple RAID levels presents storage objects with front-end tracks corresponding to back-end tracks on non-volatile drives and accesses the drives using a single type of back-end allocation unit that is larger than a back-end track. When the number of members of a protection group of a RAID level does not align with the back-end allocation unit, multiple back-end tracks are grouped and accessed using a single IO. The number of back-end tracks in a group is selected to align with the back-end allocation unit size. If the front-end tracks are variable size, then front-end tracks may be destaged into a smaller number of grouped back-end tracks in a single IO.

Group-based RAID-1 implementation in multi-RAID configured storage array

Occurrence of a RAID double failure in a slice of a RAID protection group (failed slice) renders data stored in the back-end tracks of the failed slice vulnerable to loss. When a RAID double failure is detected, a new slice is added to the RAID protection group. Front-end tracks that map to the good back-end tracks of the failed slice are moved from the back-end tracks of the failed slice to the back-end tracks of the newly added slice. Any front-end tracks that mapped to the bad back-end tracks of the failed slice are made to be write pending and written to corresponding back-end tracks of the newly added slice. Front-end tracks that map to the bad back-end tracks may be made to be write-pending in connection with a host write operation, by reading the front-end tracks from a local backup, or from a remote backup location.

Automated recovery from raid double failure

A storage array that presents a logical storage device to hosts that is accessed using front-end tracks and access tangible managed drive using back-end tracks locates multiple front-end tracks in individual back-end tracks. Error-correcting codes are used to identify different front-end tracks in a back-end track when the back-end track is copied from the managed drives into storage array memory. CKD front-end tracks can be split into multiple partial CKD front-end tracks that are located at contiguous address space in different back-end tracks. The front-end tracks that are located in a particular back-end track may be selected to reduce or minimize unused space. The front-end tracks in a back-end track may be logically stored on different production volumes.

Growing community of inventors

Needham, MA, United States of America

Lixin Pang