Emc Corporation

Emc IP Holding Company LLC

Peter John McCann

Christopher M Gould

Jeffrey Alan Brown

David W Harvey

Bradford B Glade

Matthew D Waxman

Fernando Oliveira

Lee W VanTine

James A Wentworth

Walter M Caritj

Brian James Martin

Stephen J Todd

Roy E Clark

Alan Lee Taylor

Honggang Li

Wai Chuen Yim

Peter Puhov

Douglas Sullivan

Robert Foley

Steven A Morley

Michael C Brundage

Yuval Harduf

John Kemeny

John Daniel Hushon

Michael Paul Wagner

Roko Peros

Humberto Rodriguez

Kenneth D Lee

Yechen Huang

Zhonghua Zhu

Robert J Bell, Iv

Ahia Lieber

Guifeng Tang

Zhenhua Dong

Gerry Fredette

Michael J Noeth

Jun Ohama

Inna Reznik

Thomas J McSweeney

Mike Xizhan Song

Xu Jinqing

Joe Caisse

Joseph B Caisse

Mikhail Y Simonov

Techniques for providing a fencing scheme for cluster systems without inherent hardware fencing. Storage nodes in an HA cluster communicate with one another over communication paths implemented through a variety of mechanisms, including drives and network connections. Each storage node in the HA cluster executes a fencing enforcer component operable to enforce actions or processes for initiating fencing of itself and/or initiating self-fencing of another storage node in the HA cluster determined to be malfunctioning. By providing for richer communications between storage nodes in an HA cluster and a richer set of actions or processes for fencing a malfunctioning storage node including self-fencing, the malfunctioning storage node can be made to exit the HA cluster in a more controlled fashion. In addition, a remaining storage node in the HA cluster can more safely take on the role of primary storage node with reduced risk of data corruption on shared resources.

Enhanced fencing scheme for cluster systems without inherent hardware fencing

Techniques for rebooting a node may include: performing first processing that fails to reboot the node using a primary storage device of the node; responsive to the first processing failing to reboot the node using the primary storage device of the node, performing second processing that reboots the node using a secondary storage device of the node and executes a recovery operating system of the secondary storage device; determining, by the recovery operating system executing first code, whether the primary storage device of the node meets one or more criteria indicating that the primary storage device is faulty or defective; and responsive to determining the primary storage device of the node meets the one or more criteria, performing third processing that restores the primary storage device using the secondary storage device.

Techniques for software recovery and restoration

Techniques for submitting unaligned IO data to an alignment-required IO stack of a storage system. The techniques include determining that IO data specified by an IO command contains unaligned IO data, and generating an IOCB and a tunneling IOCB. The IOCB includes information pertaining to the tunneling IOCB and the tunneling IOCB includes information pertaining to a sector-unaligned buffer for storing the IO data. The tunneling IOCB satisfies a sector-alignment requirement of an IO stack. The techniques include, in response to submitting the IO command and the information included in the IOCB to the IO stack, determining that the tunneling IOCB satisfies the sector-alignment requirement of the IO stack; having satisfied the sector-alignment requirement, building a driver command based on the IO command and the information included in the tunneling IOCB; and, transferring, by executing the driver command, the unaligned IO data from the sector-unaligned buffer to a storage device.

Systems and methods to submit unaligned IO on an alignment-required IO stack

A technique manages drive space within a storage system having a main data services environment configured to perform data storage operations on behalf of a set of hosts and a simple data services environment configured to load the main data services environment. The technique involves, while the simple data services environment is running on the storage system, using the simple data services environment to load the main data services environment on to the storage system. The technique further involves, after the main data services environment is loaded on to the storage system, providing a drive space communication from the simple data services environment to the main data services environment. The technique further involves receiving, by the simple data services environment, allocation of drive space from the main data services environment in response to the drive space communication.

Managing drive space among different data services environments within a storage system

A method, computer program product, and computing system for generating a sideband communication channel between a storage kernel driver and an error handling module of a storage system. One or more messages on the storage kernel driver may be detected. At least one message of the one or more messages may be communicated, via the sideband communication channel, from the storage kernel driver to the error handling module.

System and method for communicating messages with a sideband communication channel

Techniques are presented for implementing a scalable approach to keeping track of the metadata validity of persistently-stored metadata for storage objects. In contrast with prior approaches, improved techniques only store a list of the invalid (or quarantined) objects rather than all objects regardless of validity of their metadata. Under normal circumstances, only a small number of storage objects are invalid at any given time, as the system generally takes steps to repair the invalid objects in the normal course of operation. Thus, the number of invalid objects tends to be small, barring some catastrophic system failure. Only a small amount of expensive privileged persistent storage is therefore needed. A health level may also be used to indicate many failures, indicative of catastrophic system failure.

Quarantining storage objects using a quarantine list

Described are techniques for building a code entity. A plurality of configuration files are selected in accordance with a target and target variant. The target identifies hardware and software platform information about an environment in which the code entity is to be configured for execution. The target variant identifies a software build variation for a particular target. One or more build phases are performed using the plurality of configuration files selected in said selecting. The code entity is generated as an output of performing the one or more build phases where the code entity varies with the target and target variant.

Techniques for building code entities

A method, system, and program, product for managing scanning of databases in data storage system, the method comprising receiving a query request from an application server to a data storage system, scanning data stored in the data storage system and based on the query request, returning a set of data to the application server, wherein the set of data corresponds to the query request.

Managing scanning of databases in data storage systems

Described are techniques for providing a logical device model. In one embodiment, a a method for providing a logical device model includes providing a plurality of logical devices, at least one of said plurality of logical devices being provided by a first provider executing in kernel space and at least one of said plurality of logical devices being provided by a second provider executing in user space, and establishing a relationship between the first provider and the second provider wherein the first provider is a consumer of a logical device provided by the second provider, said logical device model including said relationship.

Logical device model

Described are techniques for creating a thread. A first plurality of calls are issued to create the thread. The first plurality of calls are executed in the context of an executing first thread and form a call chain traversing a plurality of code layers in a first order. A data area including thread-specific context information is created and initialized at each of the plurality of code layers when code of each code layer is invoked in accordance with the interface of each code layer to create the thread. Each of the plurality of code layers is included in a registered set. Executing the thread includes issuing a second plurality of calls traversing said plurality of code layers in an order that is a reverse of the first order. The second plurality of calls result in transferring control to a first body of code for the thread.

Providing hierarchical thread storage

Techniques are provided for routinely enqueuing events onto event queues by direct operation of an interrupt service routine (ISR) in kernel space when possible. Only when the event queue is unavailable does the ISR resort to offloading the enqueuing process to another kernel space thread. Unavailability can further be made uncommon by using separate event cores for different processing cores.

Efficient communication of interrupts from kernel space to user space using event queues

A technique for managing I/O operations in data storage systems having one or more multi-core processors is provided. A first variable stored in shared memory is configured to simultaneously store a counter associated with a number of I/O operations outstanding and a gate bit value associated with a gate condition. I/O operations are tracked by incrementing the counter value when an I/O operation is received and decrementing the counter value when an I/O operation is processed. If a storage object is identified as requiring a state change, the gate bit is set to queue any subsequent I/O operations. Outstanding I/O operations are drained by processing I/Os until the counter reaches zero. Any necessary operations are performed during the state change condition. The gate bit is cleared and I/O processing resumes. Atomic increment, decrement, OR and AND instructions provide synchronization across the multiple cores.

Managing I/O operations in multi-core systems

Described are techniques for executing code performing one or more operations corresponding to scheduling and synchronization primitives. During execution of the code, a call is performed using an application programming interface requesting a first of the operations corresponding to one of said scheduling and synchronization primitives. During runtime in response to said call, it is determined whether to perform the first operation. The determining step uses a set of one or more criteria indicating conditions as to when the scheduling and synchronization primitives are allowed to be performed. The one or more criteria are determined in accordance with a plurality of different platforms. If it is determined that the first operation is allowable and the first operation is to be performed, then the code can be executed on each of the different platforms in a privileged execution mode and a non-privileged execution mode.

Common scheduling and synchronization primitives

Described are techniques for performing remote procedure calls (RPCs). An RPC API is described which provides for using an optimized technique and an unoptimized technique for performing RPCs. The optimized technique includes a client container performing a call to obtain RPC configuration information which is then stored by the client container and may be used by the client container in connection with multiple RPC invocations. Techniques are also described for communicating parameter information between containers executing in different address spaces by forming parameter information on the client side using embedded lists, encoding the parameter information on the client side prior to transmission to the server, and transmitting the encoded parameter information to the server which determines output parameters and returns the output parameters to the client.

Techniques for performing a remote procedure call using remote procedure call configuration information

Described are techniques for communicating between one or more producers and one or more consumers. A first consumer of an event queue registers for notification regarding occurrences of one or more events. A producer of the event queue posts one or more notifications to one or more consumers of the event queue regarding one or more occurrences of one or more events. Each of the consumers receive notification regarding occurrences of events for which said each consumer is registered. The first consumer retrieves posted event notifications regarding events for which said first consumer is registered. If the first consumer is executing in user space and an event notification list to which said event notifications for said first consumer are posted is located in shared memory, said first consumer retrieves said posted event notifications without proxying into kernel space.

Event queues

Growing community of inventors

Mason, NH, United States of America

Peter John McCann