Emc IP Holding Company LLC

Dell Products Inc.

Dell & Products L.p.

Vamsi K Vankamamidi

Philippe Armangau

Geng Han

Shuyu Lee

Ajay Karri

Ashok Tamilarasan

Jian Gao

Amitai Alkalay

Vladimir Shveidel

Sorin Faibish

Xinlei Xu

Istvan Gonczi

Daniel E Cummins

Steven A Morley

Socheavy D Heng

Uri Shabi

Bruce E Caram

Alexander Shknevsky

Ronen Gazit

Oran Asher Baruch

Philip N Shilane

Ivan Bassov

Shaul Dar

Yubing Wang

Ivan Basov

Maor Rahamim

Maher Kachmar

Vikram A Prabhakar

Christopher A Seibel

Oran Baruch

Hongpo Gao

Yousheng Liu

Michael P Wahl

Alexei Karaban

Anton Kucherov

Lior Kamran

Christopher Alan Seibel

Vasudevan Subramanian

Nimrod Shani

Pavan Kumar Vutukuri

Mayank Ajmera

William C Davenport

Shaoqin Gong

Chun Ma

David W Harvey

Liam Xiongcheng Li

Ramakanth Kanagovi

Xiaobo Zhang

Svetlana Kronrod

Guhesh Swaminathan

Dixitkumar Vishnubhai Patel

Rongrong Shang

Samuel L Mullis, Ii

Sihang Xia

John F Gillono

Shari Vietry

Kamakshi Viswanadha

Jeffrey L Grummon

David Bernard

Charles Ma

Vikram Prabhakar

Andrew T Feld

James H Shimer

Ryan Gadsby

Swati Smita Sitha

James McCoy

Jibing Dong

Owen Martin

Jianbin Kang

Thomas Earl Linnell

Himabindu Tummala

Jamin Jianbin Kang

Richard P Ruef

Rohit K Chawla

Xiongcheng Li

Ree Sun

Thomas N Dibb

Kurt William Everson

Ronald D Proulx

Vasu Subramanian

Ming Wang

Steve Morley

Jason E Raff

Amihay Azruel

Michael Litvak

Ami Sabo

Ping Ge

Jigang Wang

Andrew P Kubicki

Bijayalaxmi Nanda

Christopher Jones

Paras Pandya

Christopher J Jones

David Ben-David

Qiu Zhong

Alex Wang

Amital Alkalay

Edward Zhao

Zhuoqun Yuan

In at least one embodiment, processing can include: partitioning a first set of CPU cores into a plurality of CPU core subsets each associated with a single corresponding one of a plurality of predefined I/O types; classifying each of a plurality of I/O requests as one of the plurality of predefined I/O types; for each of the plurality of I/O requests, selecting a CPU core from a first CPU core subset of the plurality of CPU core subsets based, at least in part, on the first CPU core subset having a corresponding one of the plurality of predefined I/O types that matches an associated one of the plurality of predefined I/O types of said each I/O request; and processing the plurality of I/O requests on their selected CPU cores.

Techniques for CPU core management based on operation types

A method of managing end-of-life processing of data blocks includes performing a decref procedure for a chunk of data, the decref procedure decrementing reference counts for respective blocks of the chunk of data, and deferring performance of an end-of-life procedure for a plurality of blocks of the chunk of data whose reference counts become zero as a result of performing the decref procedure. The method further includes, upon performing a data consolidation procedure after performing the decref procedure, performing the end-of-life procedure on the plurality of blocks.

End-of-life data page processing

For a flush request for a first block of user data directly stored into a physical block of non-volatile data storage, allocating a virtual layer block, and storing, in the virtual layer block, a first set of virtual block pointers indicating pages of the first block within the physical block. Pointers to the virtual block pointers in the first set are then stored into a leaf layer of a logical address mapping tree. The virtual layer block is identified for a subsequent flush request issued for a second block of user data directly stored into the physical block, and a second set of virtual block pointers indicating pages of the second block within the physical block is stored in the virtual layer block. Pointers to the virtual block pointers in the second set are stored into a leaf layer node of another logical address mapping tree.

Flushing directly ingested user data

In at least one embodiment, processing can include: receiving a write that writes content to a logical address; recording an entry for the write in a log; flushing the entry from the log; recording, in a metadata log, an update to a metadata page; flushing the update from the metadata log; generating an updated version of the metadata page including the update; staging the updated version of the metadata page to a staging area of a plurality of partitions, comprising: selecting a partition of the staging area based on: a partition owner of the partition, a page owner of the metadata page, a type of the metadata page, and a second type of the first partition; selecting a zone of the partition based on a processing node performing said staging; and writing the updated version of the metadata page to the zone of the partition.

Techniques for staging updated metadata pages based on owner and metadata

A technique that processes write operation information involves receiving, as the write operation information, user data and corresponding metadata. The technique further involves generating inflated data which includes the user data and the corresponding metadata. The inflated data has a size that is larger than a total (or overall) size of the user data and the corresponding metadata. Additionally, the inflated data naturally aligns on storage boundaries of solid state device (SSD) storage (non-volatile flash memory). The technique further involves, after generating the inflated data, storing the inflated data in the SSD storage.

Processing write operation information using inflated data

A technique is directed to providing data storage resiliency. The technique includes, after losing access to a storage device that provides storage to a storage extent, performing a degraded write operation that writes data to a first line of the storage extent. The technique further includes setting a first indicator to indicate that the first line was written to while access to the storage device was lost and while a second indicator continues to indicate that a second line of the storage extent was not written to. The technique further includes, after regaining access to the storage device and in response to the first indicator indicating that the first line was written to in the degraded write operation, performing a resiliency operation that constructs additional data from the data written in the first line to increase data storage resiliency of the storage extent.

Providing data storage resiliency

A method, computer program product, and computing system for maintaining a pointer quantity count for each of a plurality of virtual mapping groups, wherein each virtual mapping group is associated with a duplicative data portion within a storage platform and each pointer quantity count defines the number of pointers included within the corresponding virtual mapping group; and obtaining a hash value for a specific duplicative data portion associated with a specific virtual mapping group if a specific pointer quantity count for the specific virtual mapping group is reduced to zero.

System and method for hash-based data deduplication

A method, computer program product, and computing system for expanding the lifetime of virtual entries in a data storage system. A deduplication function of a virtual layer of a data storage system is monitored, a reference count of a virtual entry is incremented when a data page is written to a physical layer of the data storage system and the reference count of the virtual entry is decremented when a data page is deleted from the virtual layer. The virtual entry in the virtual layer is maintained when the reference count reaches a predetermined value and the virtual entry is reclaimed when a predetermined action of the data storage system is to be performed.

System and method for expanding the lifetime of virtual entries in data storage systems

Techniques for limiting or reducing storage accessibility 'hiccups' in active-active clustered systems that perform large writes. The techniques can include executing, by a surviving, failover, or rebooted node of an active-active clustered system, a specialized recovery protocol that includes treating each large write request from a host computer as a plurality of small write requests while execution of the specialized recovery protocol is in progress, draining all dedicated sub-ubers for a primary and secondary node of the active-active clustered system, and, having completed execution of the specialized recovery protocol, resuming normal treatment of large write requests from the host computer. In this way, the need and complexity of managing large writes and maintaining their corresponding sub-uber information during recovery from a forced reboot, crash, or disaster involving the primary or secondary node can be avoided, and storage accessibility hiccups due to performing the large writes can be limited or reduced.

Low hiccup time fail-back in active-active dual-node storage systems with large writes

Techniques can include: receiving, at a first node, a read I/O directed to a logical address; determining that the first node does not own the logical address; sending over an interconnect a redirect request from the first node to a second node that owns the first logical address; and the second node performing processing including: determining, in accordance with one or more criteria, whether the interconnect is overloaded; responsive to determining that the interconnect is not overloaded, sending a redirect reply over the interconnect to the first node where the redirect reply includes first content stored at the first logical address; and responsive to determining that the interconnect is overloaded, sending the redirect reply over the interconnect to the first node where the redirect reply includes physical location information identifying a first physical storage location or address on non-volatile storage of the first content of the first logical address.

I/O processing techniques in a multi-node system

A method, computer program product, and computing system for receiving a metadata page for storage within a log-structured metadata store. An entry may be generated within a translation table page of a translation table within the log-structured metadata store, wherein each entry of a plurality of entries within the translation table page is associated with a separate metadata page. One or more metadata page deltas for the metadata page may be recorded in the log-structured metadata store. The one or more metadata page deltas for the metadata page may be flushed to a persistent memory storage. In response to flushing the one or more metadata page deltas for the metadata page, the entry within the translation table page that is associated with the metadata page may be updated without accessing any other entry within the translation table page associated with other metadata pages.

System and method for managing metadata access in a log-structured system

In at least one embodiment, processing can include: receiving, from a client, a request to access a metadata (MD) page, wherein the request specifies a lock type denoting a particular level of access to the MD page that is being requested by the request; and responsive to receiving the request, performing first processing including: locking the MD page and a corresponding translation table entry Efor the MD page in accordance with the lock type denoting a particular level of access being requested, wherein Emaps a logical address LAof the MD page to a physical storage or location PAon non-volatile storage where the MD page is stored; and subsequent to said locking, returning a response including the MD page to the client.

Techniques for destaging translation table updates and accessing translation table entries in a log-structured system

In at least one embodiment, processing can include: recording write operations as entries in a log; flushing the entries from the log, said flushing including persistently storing, on non-volatile storage, content written by the write operations; responsive to determining a system has a current workload below a specified workload threshold, performing first processing including: determining a first minimum number of free blocks of the non-volatile storage based on: i) an average number of free blocks expected to be consumed in connection with flushing the log in each time interval, ii) a constant, and iii) a second minimum number of blocks denoting an upper bound of a number of blocks of the non-volatile storage consumed by flushing the log in each time interval; and responsive to determining that a current number of free blocks is less than the first minimum number, performing garbage collection processing on the non-volatile storage.

Data storage management techniques

A technique is directed to managing wear leveling between storage devices. The technique includes obtaining a wear level metric of a candidate storage extent that includes storage from multiple storage devices. The technique further includes performing an assessment operation that provides an indication that the candidate storage extent satisfies an access criterion. The access criterion is based on the wear level metric. The technique further includes, in response to the assessment operation providing the indication that the candidate storage extent satisfies the access criterion, performing a set of access operations that accesses the candidate storage extent.

Managing storage extents using wear levels

A technique of managing writes in a data storage system includes receiving I/O requests specifying data to be written, storing a set of the data to be written in an extent of a data log, and preventing data reduction from being performed on the set of data in the extent for at least a specified time interval, said time interval enabling portions of the set of data to be overwritten with new data and rendering data reduction of such portions unnecessary.

Avoiding data reduction debt for quickly overwritten data

Growing community of inventors

Hopkinton, MA, United States of America

Vamsi K Vankamamidi