Dell Products Inc.

Emc IP Holding Company LLC

Parmeshwr Prasad

Rahul Deo Vishwakarma

Bing Liu

Shelesh Chopra

Viswanath Ponnuru

Parminder Singh Sethi

Sumanth Vidyadhara

Ravishankar Kanakapura Nanjundaswamy

Shekar Babu Suryanarayana

Anusha Bhaskar

K N Ravishankar

Shishir Choubey

Owen Martin

Chandrashekar Nelogal

Yogesh Prabhakar Kulkarni

Mahantesh M Ambaljeri

Sharath Talkad Srinivasan

Rajib Saha

Earl Medeiros

Gopal Singh

Niladri Bhattacharya

Vaishnavi Kundathi Rajendra

Binoy Samuel Thomas

Shreedhara Hm

Michael J Scharland

Raveendra Babu Madala

Rahul Gupta

Santosh Hanamant Gore

Vijay Bharat Nijhawan

Shinose Abdul Rahiman

Smruti Ranjan Debata

Hemant Ramesh Gaikwad

Gobind Vijayakumar

Raghavendra Venkataramudu

Muniswamy Setty K S

Krishnakumar Narasimhan

Rushyendra Velamuri

Bharath Koushik Bangalore Suryanarayana

Vaideeswaran G

Muniswamy Setty

Faizal Saidalavi Nabeesa

Srinivas G Gowda

Ashish Bunkar

Suraj D Vithalkar

Vulnerability proofing a node (e.g., an Information handling System (IHS)) while onboarding the node to a container orchestration platform may include detecting onboarding of the node IHS to the container orchestration platform, which includes vulnerability management service instructions and an onboarding handler component. The onboarding including configuring (a) hardware component(s) of the IHS, and the vulnerability proofing may include executing the vulnerability management service instructions, which results in accessing (a) catalog(s) specifying known vulnerabilities of hardware components of the IHS and determining whether any of the configuring of any of the configurations of (a) hardware component(s) of the IHS are identified as vulnerable in the catalog(s). The onboarding of the IHS to the container orchestration platform by the IHS may be blocked until configuring the hardware component(s) of the IHS is modified to include no configuring of the hardware component(s) with vulnerabilities identified in the catalog(s).

Vulnerability proofing a node while onboarding to a container orchestration platform

Vulnerability proofing container orchestration platform deployment includes a remote access controller detecting a container orchestration platform installer comprising vulnerability management service instructions and executing the vulnerability management service instructions. This causes the remote controller to identify configurations for one or more of the hardware component(s) of the IHS in the container orchestration platform installer, access a plurality of catalogs specifying known vulnerabilities of hardware components and determine whether the hardware component configuration(s) in the container orchestration platform installer are identified as vulnerable in one or more of the catalogs. The remote controller blocks use of the container orchestration platform installer by the IHS until the hardware component configurations within the container orchestration platform installer are modified to include no configurations with vulnerabilities identified in the plurality of catalogs.

Vulnerability proofing container orchestration platform deployment

Techniques for intelligently routing IO to a storage class memory (SCM) namespace are disclosed. A configuration for a namespace is determined, where the configuration indicates a type of IO that the namespace is structured to handle. Details about the configuration of the namespace are stored in a repository. A forwarding rule is generated based on the namespace's stored configuration. When incoming IO having attributes similar to that type is received, implementation of the forwarding rule causes the incoming IO to be directed to the namespace. Attributes of a particular incoming IO are determined. As a result of the attributes satisfying a similarity threshold relative to the type, the forwarding rule is implemented such that the particular incoming IO is directed to the namespace.

Forwarding incoming IO to SCM namespaces

One example method includes accessing a dataset, selecting a list of attributes of the dataset, each of the attributes being selected based on a determination that the attribute is affecting growth of the dataset and affecting an amount of data storage space consumed by the dataset, assigning a SHAP score to each attribute, using the SHAP scores to assign respective weights to each attribute, deriving drift and shock information for the dataset, and based on the drift and shock information, calculating a risk score that a storage capacity of an asset where the dataset is stored will be exhausted within a particular time interval.

Stochastic risk scoring with counterfactual analysis for storage capacity

One example method includes collecting respective data for each datastore in a group of datastores, clustering the data, based on the clustering, applying one of two different mutually exclusive labels to each of the datastores, applying an uncertainty quantifier to determine, for each datastore, a confidence level that the label assigned to that datastore is the correct label, ranking the datastores according to their respective label and confidence level, and presenting, to a user, a list that includes at least a datastore with a highest confidence level.

Smart datastore selection for protection engines based on uncertainty quantification

One example method includes analyzing an IO pattern comprising IOs issued by a client application, based on the analyzing, generating a rule relating to an NFIT, using the rule to modify the NFIT, and after the NFIT is modified, changing a configuration of SCM firmware based on the NFIT. Because the modified SCM firmware may have a configuration directly related to the IO pattern, the SCM may function relatively more efficiently and effectively for that IO pattern.

Based on IO pattern influence NFIT table for persistence for SCM firmware

Architectures and techniques are described that, in the context of a microservice platform, can provide automated discovery and configuration of message brokers on behalf of resident microservices. As a result, microservices no longer need to be tightly bound to a particular message broker. Hence, significant coding changes for microservices developers can be avoided over the lifetime of a particular microservice.

Automated message broker discovery

Embodiments for storing digital data in DNA storage by receiving input file data, encoding the input file data into an oligonucleotide sequence to produce sequence data through a transformation of text to binary to Base_3 encoding, organizing the Base_3 sequence data into chunks of a defined chunk size, and storing the chunks in a block of a blockchain. The oligonucleotide sequence may comprise metadata for the input file data that refers to actual data stored in the DNA storage, where the actual data is formed by synthesizing the oligonucleotide sequence in a DNA synthesis process. The chunks may be stored in the blockchain only if the block agrees with a smart contract defined for the oligonucleotide sequence.

Securely archiving digital data in DNA storage as blocks in a blockchain

A memory device defines portions of the storage space as memory mode memory or storage mode memory. Memory mode memory is represented as a portion of a system physical address space of an information handling system, and storage mode memory is represented as a storage device in the information handling system. An operating system instantiates a paged virtual memory architecture on the information handling system. The information handling system determines a page miss rate for pages stored in the first portion of the storage space, receives a request to increase a first size of the first portion of storage space in response to determining the page miss rate, and increases the first size of the first portion of storage space to a second size in response to the request.

System and method for storage class memory tiering

Embodiments include a method of storing digital data in a blockchain by receiving the digital data from a user, deduplicating the data in a deduplication system of the user to form deduplicated data, and encoding the deduplicated data into an array format for storage on a blockchain. A smart contract is deployed for deduplication on the destination side of the data, and the deduplicated data is encoded into a Binary Aligned Map (BAM) format for storage on the blockchain. A process on the destination side stores the deduplicated array data as a next block in the blockchain only if the next block agrees with the smart contract, and the blockchain is stored in system storage comprising hard disk, solid state, tape, or optical devices.

Storing digital data in storage devices using smart contract and blockchain technology

Systems and methods are provided for context-aware maintenance window identification. In some embodiments, an Information Handling System (IHS) may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to: estimate a completion time of a maintenance operation; predict future usage of the IHS; identify a time window for the maintenance operation based upon the estimation and the prediction.

Context-aware maintenance window identification

A message broker resource monitoring service obtains message broker resource parameter data of a resource, based on communications of a message broker. Based on the resource parameter data and historical data, the message broker resource monitoring service obtains a predicted message delivery time value, which can be in association with confidence. If the predicted message delivery time value satisfies a resource deletion criterion, e.g., the predicted message delivery time value, with sufficient confidence, exceeds a threshold value, the message broker resource monitoring service triggers an action to delete the resource. To obtain the predicted value, a regression such as symmetric conformal quantile regression can be applied to the parameter data, e.g., to obtain a predicted message delivery time/latency value.

Message broker resource deletion

A method for managing a resource system includes obtaining, by a hardware resource manager, a firmware update lockdown request for a lockdown for a firmware device of the resource system, in response to the firmware update lockdown request: identifying a firmware protocol corresponding to the firmware device, generating a firmware lockdown command corresponding to the firmware device based on the firmware protocol, and initiating updating of a lockdown policy based on the firmware lockdown command.

System and method for managing update installation lockdown policies for firmware devices and driver-managed devices

Non-volatile Random Access Memory (NVR) on a storage system may be dynamically converted between use as temporary memory in a memory context and use as persistent memory in a storage context. NVR (e.g., embodied as DIMM) may be utilized in a hybrid capacity, where some of the NVR is used as memory and some of the NVR is used as storage, and where NVR memory is converted to memory as needed, dynamically as I/O is being processed using the NVR. A host system may be directly connected to an internal switching fabric of the data storage system without an intervening component of the storage system (e.g., a director) controlling access of the host system to the internal fabric or to the memory. The host system may provision and use the NVR as storage by directly communicating with the NVR over the internal fabric, for example, using RDMA.

Dynamic use of non-volatile ram as memory and storage on a storage system

Growing community of inventors

Bengaluru, India

Parmeshwr Prasad