Netapp, Inc.

Network Appliance, Inc.

Vmware, Inc.

Aechelon Technology, Inc.

Bracket Computing, Inc.

William McGovern

Jeffrey L Heller

Jason Ansel Lango

John K Edwards

Andrew G Tucker

Nitin Bahadur

J Christopher Wagner

Thomas Holland

Jeffrey Dale Merrick

Josh Silberman

Adam Cain

Kevin George

Robert M English

Robert L Fair

Stephen Lee Manley

Ignacio Sanz-Pastor

Joshua Oren Silberman

Javier Castellar

David Morgan Robles

Mehul S Shah

Yasuhiro Endo

Luis A Barcena

Wayne Ando

Jozef Tupy

Jason Sylvain

In an embodiment, a secure boot method comprises writing a wrapped data encryption key (DEK) and a wrapped key encryption key (KEK) onto a label of a wrapped operating system image prior to uploading the wrapped operating system image to a virtual data center using one or more computing devices.

Secure boot of virtualized computing instances

In an approach, a secure boot process includes two phases. In the first phase an on premises device generates a data encryption key (DEK) with which to encrypt an operating system image and a key encryption key (KEK) with which to wrap the DEK. The on-premises device then utilizes a key management service to wrap the KEK with an account root key and writes the wrapped DEK and wrapped KEK onto a label of the encrypted operating system image. The encrypted operating system image is then uploaded to a virtual data center and merged with an intermediary guest manager image. When the encrypted machine image is used to generate a virtual machine instance, the intermediary guest manager utilizes the key management service to unwrap the KEK. The unwrapped KEK is then used to unwrap the wrapped DEK which is then used to launch the encrypted guest operating system.

Aspects of the present invention provide a method of specifying a device driver design for a board device. The method includes receiving a board device with various functional elements and on-board storage to be operatively coupled to a computing device through an interconnect. The device driver design is specified through the identification of one or more device driver parameters. The device driver parameters are to be used subsequently to customize an adaptive device driver that interfaces with the board device and each of the one or more functional elements. Device driver parameters are stored in a predetermined storage construct allocated from the board device. These device driver parameters remain stored in the storage construct until there is a need for the board device and corresponding device driver. Customizing the adaptive device driver is done after the device driver parameters have been stored and typically when a computer device starts or 'boots'. Initially, aspects of the present invention may receive an indication that a board device and one or more functional elements associated with the board device have been attached to an interconnect and requires a device driver. Next, aspect of the present invention retrieve device driver parameters from the storage constructs and customizes the adaptable device driver into a device driver for the board device in accordance with the device driver parameters.

Adaptive device driver method and system

Method and system are provided for handling data when power failure from a primary power source of a storage system is detected. The system provides a first memory and a second memory. The first memory is primarily used to store data when the primary power source is operating. If a power failure is detected, a first indicator is set to indicate that data is stored or being transferred to the second memory. Thereafter, data is transferred from the first memory to the second memory. Any errors during the transfer are logged. Once power is restored, data is transferred back to the first memory. A second indicator is set to indicate that there is no data at the second memory.

Redundant memory system and associated method thereof

Multiple domains are created for processes of a storage server. The processes are capable of execution on a plurality of processors in the storage server. The domains include a first domain, which includes multiple threads that can execute processes in the first domain in parallel, to service data access requests. A data set managed by the storage server is logically divided into multiple subsets, and each of the subsets is assigned to exactly one of the threads in the first domain, for processing of data access requests directed to the data set.

Mutual exclusion domains to perform file system processes on stripes

A write-once-read-many (WORM) storage system that employs large-capacity and relatively inexpensive disks in connection with a file system on a file server is provided. The file system contains most or all of the required WORM functionality so as to impose a minimal footprint on client applications, client operating systems and open protocols if desired. The system is organized around WORM storage volumes that contain files that, when committed to WORM storage, cannot be deleted or modified. Any file path or directory tree structure used to identify the file within the WORM volume is locked and cannot be deleted. In one embodiment, the administrator creates a WORM volume, capable of storing designated WORM files. The client then creates an appropriate WORM file using the appropriate protocol semantics. The file is written to the volume and committed by transitioning the file attributes from a not-read-only to a read-only state. The file system recognizes the persistently stored WORM attribute of any file in a WORM volume as WORM file. Henceforth, any attempt to modify the file attributes, write to the file, or delete the file, by clients, administrators or other entities is rejected and a request denied message is returned to the attempting party.

Write-once-read-many storage system and method for implementing the same

A system and method are provided for storing request information in separate memory, in response to the detection of a power failure. This is accomplished by detecting the power failure and, in response, storing the request information in separate memory utilizing a secondary power source. By this feature, the request information is safely stored during a period of power failure. To this end, in various embodiments, the request information may be stored for later use in satisfying corresponding requests when power is restored.

Power failure system and method for storing request information

According to an embodiment of the invention, a storage server is mirrored onto a mirroring server. The mirroring server maintains point-in-time images of data stored on the storage server. The point-in-time images have a retention period. During the retention period, the point-in-time images must be maintained to comply with 17 C.F.R. 240.17a-4 (the 'Rule'). When a command to delete a point-in-time image is issued, the file system of the mirroring server references a table including a list of point-in-time images and their retention dates. If the current date is greater than the retention date, the point-in-time image is deleted. If the current date is less than the retention date, the point-in-time image cannot be deleted.

Method and apparatus for maintaining compliant storage

This invention provides a specified retention date within a data set that is locked against deletion or modification within a WORM storage implementation. This retention date scheme does not utilize any proprietary application program interfaces (APIs) or protocols, but rather, employs native functionality within conventional file (or other data containers, data sets or block-based logical unit numbers) properties available in commonly used operating systems. In an illustrative embodiment, the retention date/time is calculated by querying the file's last-modified time prior to commit, adding the retention period to this value and thereby deriving a retention date after which the file can be released from WORM. Prior to commit, the computed retention date is stored in the file's 'last access time' property/attribute field, or another metadata field that remains permanently associated with the file and that, in being used for retention date, does not interfere with file management in a WORM state. Since this field is not utilized in a WORM context, it can be adapted to store this date. Once stored, the retention date in this field is locked against modification. Where extension (never reduction) of a retention period is desired, the last access time field be updated, wherein the new retention period is added to the existing last access time value to derive a new, later retention date for the file. Upon expiry of the retention date, the system allows deletion of the expired WORM file/data set.

System and method for record retention date in a write once read many storage system

A storage system includes a host computer coupled to a device to transfer a DMA descriptor between the host and the device. An integrity manager manages the integrity of the DMA descriptor between the host computer and the device. The integrity manager embeds a host-side DMA descriptor integrity value in the DMA descriptor and the device transfers the DMA descriptor to a device memory. The device generates a device-side DMA descriptor integrity value and compares it to the host-side DMA descriptor integrity value to determine if the descriptor is corrupted.

Preserving data integrity of DMA descriptors

A file system in a storage system allows a user to designate data as write-once read-many (WORM) data. The WORM data are stored in a first set of storage media of the storage system. Signature data are generated from the WORM data. Using the signature data, the integrity of the WORM data can be verified.

Method and apparatus for verifiably migrating WORM data

A system is provided to commit data to persistent storage. The system comprises a configuration component to set an autocommit period, a scanner to detect that the autocommit period has expired for a file and a commit component to commit the file to write once read many (WORM) status In one embodiment, when an autocommit period is set, the system may be configured to automatically commit a file to WORM status if the file has not been changed for the autocommit period.

Method and apparatus to automatically commit files to WORM status

A technique for partially offloading, from a main cache in a storage server, the storage of cache tags for data blocks in a victim cache of the storage server, is described. The technique includes storing, in the main cache, a first subset of the cache tag information for each of the data blocks, and storing, in a victim cache of the storage server, a second subset of the cache tag information for each of the data blocks. This technique avoids the need to store the second subset of the cache tag information in the main cache.

Growing community of inventors

San Jose, CA, United States of America

William McGovern