Source: http://www.google.com/patents/US6678788?dq=7,403,220
Timestamp: 2017-02-21 16:57:38
Document Index: 563537330

Matched Legal Cases: ['ART 72', 'ARTs 72', 'ART 72', 'art 90', 'ARTs 72', 'ART 72', 'ART 72', 'ARTs 72', 'ARTs 72', 'ARTs 72', 'ART 72', 'ART 72', 'ART 72', 'ARTs 72', 'ART 72', 'art 90', 'ART 72', 'ART 72', 'ART 72', 'ART 72', 'ART 72']

Patent US6678788 - Data type and topological data categorization and ordering for a mass ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsThe storage space of a RAID striped mass storage system is topologically organized as a plurality of basic units of storage space for storing data items in data blocks. A topological data formatter includes a write data buffer for each data type and an initial data classifier initially categorizes each...http://www.google.com/patents/US6678788?utm_source=gb-gplus-sharePatent US6678788 - Data type and topological data categorization and ordering for a mass storage systemAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS6678788 B1Publication typeGrantApplication numberUS 09/579,671Publication dateJan 13, 2004Filing dateMay 26, 2000Priority dateMay 26, 2000Fee statusPaidPublication number09579671, 579671, US 6678788 B1, US 6678788B1, US-B1-6678788, US6678788 B1, US6678788B1InventorsMark Andrew O'ConnellOriginal AssigneeEmc CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (2), Referenced by (143), Classifications (14), Legal Events (6) External Links: USPTO, USPTO Assignment, EspacenetData type and topological data categorization and ordering for a mass storage system
US 6678788 B1Abstract
The storage space of a RAID striped mass storage system is topologically organized as a plurality of basic units of storage space for storing data items in data blocks. A topological data formatter includes a write data buffer for each data type and an initial data classifier initially categorizes each data item as a structured data type having defined data characteristics or a general data type having variable data characteristics and writes each structured data type data item into a corresponding type buffer. A topological data classifier topologically categorizes each general data type data item as a full-basic unit data type forming data blocks or as a partial-basic unit data type forming partial data blocks and writes each data item into corresponding full-basic type buffer or partial-basic type buffer. Upon a write to storage space, the initial data classifier orders structured data type data items into data block groups corresponding to a basic storage units and writes the data block groups into corresponding areas of storage space. The topological data classifier re-executes the topological classification of full-basic and partial-basic unit data type data items, orders the data items into full-basic or partial-basic unit data block groups, and writes the data block groups into corresponding areas of storage space.
What is claimed is: 1. In a mass storage system including a mass storage space for storing data items of a plurality of data types, each data item containing data of a corresponding data type and each data type being defined by the characteristics of the information represented by the data, and wherein the storage space is topologically organized as a plurality of basic units of storage space wherein each basic unit of storage space contains storage space for a predetermined number of data blocks of predetermined sizes, a method for storing the data in the storage space, comprising the steps of:
categorizing each data item to be written into the storage space as a member of a data type, including performing an initial categorization of each data item to identify whether a data item is a member of one of a plurality of one or more structured data types, having defined data characteristics or a least one general data type having variable data characteristics, and writing each data item that is a member of the one or more structured data types into a corresponding type buffer, and performing a topological categorization of each data item that is a member of at least one general data type and identifying whether each data item that is a member of at least one general data type is a full-basic unit data type wherein the data of the data items form one or more data block groups wherein each data block group conforms to the basic unit of storage space, or a partial-basic unit data type wherein the data of the data items form one or more data block groups wherein each data block group differs from the basic unit of storage space, and writing each data item that is a full-basic unit data type into a full-basic type buffer, and writing each data item that is a partial-basic unit data type into a partial-basic type buffer, upon performing a write of the data items to the mass storage, reading each data item from the corresponding type buffer, and for each data item of a structured data type, ordering the data of the data items into one or more data block groups wherein each data block group corresponds to a basic unit of storage, and writing the one or more data block groups of each structured data type into a corresponding data type area of the storage space, for each data item of the full-basic unit type and of the partial-basic unit type, re-executing the topological classification of each data item and re-categorizing each data item as a full-basic unit data type or as a partial-basic unit data type, and ordering the data of each data item of a full-basic unit data type and the data of each data item of a partial-basic unit data type into one or more corresponding full-basic unit data block groups or one or more corresponding partial-basic unit data block groups wherein each data block group corresponds to a basic unit of storage, and writing the full-basic unit data block groups and the partial-basic unit data block groups into corresponding data type areas of the storage space. 2. The method of claim 1 for storing data in a storage space, further comprising the step of:
upon writing each data item into a corresponding type buffer, and when the data of a data item being written into a type buffer and the data of one or more data items residing in the type buffer form a full-basic unit of storage space, combining the data items forming a full-basic unit of storage space. 3. The method of claim 1 for storing data in a storage space, further comprising the step of:
returning all data items forming partial-basic unit data block groups to the corresponding type buffers for re-ordering into full-basic unit data block groups in a subsequent write to the storage space. 4. The method of claim 1 for storing data in a storage space, wherein:
each basic unit of storage space is a stripe of a striped mass storage system and wherein each stripe contains storage space for a predetermined number of data blocks. 5. The method of claim 4 for storing data in a storage space, wherein:
the mass storage system is a RAID technology storage system and wherein each stripe further includes at least one data block for storing data recovery information. 6. The method of claim 1 for storing data in a storage space, wherein:
the mass storage space is structured into a plurality of data partitions wherein each data partition corresponds to a data type and is used to store data of the corresponding data type. 7. In a mass storage system including a mass storage space for storing data items of a plurality of data types, each data item containing data of a corresponding data type and each data type being defined by the characteristics of the information represented by the data, and wherein the storage space is topologically organized as a plurality of basic units of storage space wherein each basic unit of storage space contains storage space for a predetermined number of data blocks of predetermined sizes, a topological data formatter for storing the data in the storage space, comprising:
a write data buffer corresponding to each data type; an initial data classifier for data type categorizing of each data item to be written into the storage space as a member of a data type, including performing an initial categorization of each data item to identify whether a data item is a member of a structured data type having defined data characteristics or a general data type having variable data characteristics, and writing each data item that is a member of a structured data types into a corresponding type buffer, and a topological data classifier for topological categorizing of each data item that is a member of a general data type and identifying whether each data item that is a member of a general data type is a full-basic unit data type wherein the data of the data items form one or more data block groups conforming to the basic unit of storage space or a partial-basic unit data type wherein the data of the data items form one or more data block groups differing from the basic unit of storage space, writing each data item that is a full-basic unit data type into a full-basic type buffer, and writing each data item that is a partial-basic unit data type into a partial-basic type buffer, wherein upon performing a write of the data items to the mass storage, the initial data classifier reads each data item from the corresponding type buffer and, for each data item of a structured data type, orders the data of the data items into one or more data block groups wherein each data block group corresponds to a basic unit of storage and writes the one or more data block groups of each structured data type into a corresponding data type area of the storage space, and for each data item of the full-basic unit type and of the partial-basic unit type, the topological data classifier re-executes the topological classification of each data item as a full-basic unit data type or as a partial-basic unit data type, orders the data of each data item of a full-basic unit data type and the data of each data item of a partial-basic unit data type into one or more corresponding full-basic unit data block groups or one or more corresponding partial-basic unit data block groups, and writes the full-basic unit data block groups and the partial-basic unit data block groups into corresponding data type areas of the storage space. 8. The topological data formatter of claim 7 wherein:
upon writing each data item into a corresponding type buffer, the topological data formatter combines the data of a data item being written into a type buffer and the data of one or more data items residing in the type buffer to form a full-basic unit of storage space. 9. The topological data formatter of claim 7, wherein:
upon performing a write of the data items to the mass storage, the topological data formatter returns all data items forming partial-basic unit data block groups to the corresponding type buffers for re-ordering into full-basic unit data block groups in a subsequent write to the storage space. 10. The topological data formatter of claim 7, wherein:
each basic unit of storage space is a stripe of a striped mass storage system and each stripe contains storage space for a predetermined number of data blocks. 11. The topological data formatter of claim 10, wherein:
the mass storage system is a RAID technology storage system and each stripe further includes at least one data block for storing data recovery information. 12. The topological data formatter of claim 7, wherein:
the mass storage space is structured into a plurality of data partitions wherein each data partition corresponds to a data type and is used to store data of the corresponding data type. 13. A topological data formatter for writing data blocks of data items of a plurality of data types into a storage space of a mass storage system topologically organized as basic units of storage space, comprising:
a write data buffer for each data type, an initial data classifier for initially categorizing each data item as a structured data type having defined data characteristics or a general data type having variable data characteristics and writing each structured data type data item into a corresponding type buffer, and ordering the structured data type data items into data block groups corresponding to a basic storage units and writing the data block groups into corresponding areas of storage space, and a topological data classifier for topologically categorizing each general data type data item as a full-basic unit data type forming data blocks or as a partial-basic unit data type and writing each general data type data item into a corresponding full-basic type buffer or partial-basic type buffer, and re-executing the topological classification of buffered full-basic and partial-basic unit data type data items, ordering the data items into full-basic or partial-basic unit data block groups, and writing the data block groups into corresponding areas of storage space. 14. A method for topologically formatting and writing data blocks of data items of a plurality of data types into a storage space of a mass storage system topologically organized as basic units of storage space, comprising the steps of:
categorizing each data item as a structured data type having defined data characteristics or a general data type having variable data characteristics and writing each structured data type data item into a corresponding type buffer, topologically categorizing each general data type data item as a full-basic unit data type forming data blocks or as a partial-basic unit data type and writing each general data type data item into a corresponding full-basic type or partial-basic type buffer, re-executing the topological classification of buffered full-basic and partial-basic unit data type data items, ordering the buffered data items into data block groups, and writing the data block groups into areas of storage space corresponding to the data types of the data items. Description
U.S. patent application Ser. No. 09/580,539 filed May 26, 2000 by Earle Trounson MacHardy Jr. and Mike Aram de Forest for a FAULTTOLERANT, LOW LATENCY SYSTEM RESOURCE WITH HIGH LEVEL LOGGING OF SYSTEM RESOURCE TRANSACTIONS AND CROSS-SERVER MIRRORED HIGH LEVEL LOGGING OF SYSTEM RESOURCE TRANSACTIONS; now U.S. Pat. No. 6,578,160;
U.S. patent application Ser. No 09/579,427 filed May 26, 2000 by Mark Andrew O'Connell for TOPOLOGICAL DATA CATEGORIZATION AND FORMATTING FOR A MASS STORAGE SYSTEM; and,
The present invention pertains to a method and apparatus for storing data in a mass storage system and, in particular, for a method and apparatus for storing data in a mass storage system, and in particular a mass storage system implementing RAID technology, by data type and topological categorization and ordering.
Considering networked file server systems as a typical example of a shared system resource of the prior art, the filer server systems of the prior art have adopted a number of methods for achieving fault tolerance in client/server communications and in the file transaction functions of the file server, and for data recovery or reconstruction. These methods are typically based upon redundancy, that is, the provision of duplicate system elements and the replacement of a failed element with a duplicate element or the creation of duplicate copies of information to be used in reconstructing lost information. For example, many systems of the prior art employ multiple, duplicate parallel communications paths or multiple, duplicate parallel processing units, with appropriate switching to switch communications or file transactions from a failed communications path or file processor to an equivalent, parallel path or processor, to enhance the reliability and availability of client/file server communications and client/client file system communications. Yet other methods of the prior art utilize information redundancy to allow the recovery and reconstruction of transactions lost due to failures occurring during execution of the transactions. These methods include caching, transaction logging and mirroring wherein caching is the temporary storage of data in memory in the data flow path to and from the stable storage until the data transaction is committed to stable storage by transfer of the data into stable storage, that is, a disk drive, or read from stable storage and transferred to a recipient. Transaction logging, or journaling, temporarily stores information describing a data transaction, that is, the requested file server operation, until the data transaction is committed to stable storage, that is, completed in the file server, and allows lost data transactions to be re-constructed or re-executed from the stored information. Mirroring, in turn, is often used in conjunction with caching or transaction logging and is essentially the storing of a copy of the contents of a cache or transaction log in, for example, the memory or stable storage space of a separate processor as the cache or transaction log entries are generated in the file processor.
The increased power and speed of contemporary networked computer systems, however, has resulted in a corresponding demand for significantly increased mass storage capability because of the increased volumes of data dealt with by the systems and the increased size of the operating system and applications programs executed by such systems. Most mass storage devices, however, are characterized by relatively low data access and transfer rates compared to the computer systems with operate with the data and programs stored therein. As a consequence, and although the mass storage capabilities of host computer systems has been increased significantly, the speed of data read and write access has not increased proportionally. While there have been many attempts in the prior art to solve the problem of data access speed for mass storage systems, they have typically taken the form of increasing the number of disk drives, for example, to store related data items and their associated parity information across several drives in parallel, thereby overlapping the initial data access time to each drive and increasing the efficiency of bus transfers. An extreme manifestation of this approach was found, for example, in the Thinking machines Corporation CM-2 system which operated with 39 bit words, each containing 32 data bits and 7 parity bits, and stored the bits of each word in parallel across 39 disk drives, on bit to each drive.
The present invention is directed to a method and apparatus for storing data in a mass storage system, and in particular a mass storage system implementing RAID technology, by data type and topological categorization and ordering.
According to the present invention, a mass storage system includes a mass storage space for storing data items of a plurality of data types wherein each data item contains data of a corresponding data type and each data type is defined by the characteristics of the information represented by the data and wherein the storage space is topologically organized as a plurality of basic units of storage space wherein each basic unit of storage space contains storage space for a predetermined number of data blocks of predetermined sizes. A topological data formatter for storing the data in the storage space includes a write data buffer for and corresponding to each data type and an initial data classifier for data type categorizing of each data item to be written into the storage space as a member of a data type by performing an initial categorization of each data item to identify whether a data item is a member of a structured data type having defined data characteristics or a general data type having variable data characteristics. The initial data classifier then writes each data item that is a member of a structured data types into a corresponding type buffer and provides each data item that is a member of a general data type of a topological data classifier. The topological data classifier performs a topological categorization of each data item that is a member of a general data type and identifies whether each data item that is a member of a general data type is a full-basic unit data type wherein the data of the data items form one or more data block groups conforming to the basic unit of storage space or a partial-basic unit data type wherein the data of the data items form one or more data block groups differing from the basic unit of storage space. The topological data classifier then writes each data item that is a full-basic unit data type into a full-basic type buffer and writes each data item that is a partial-basic unit data type into a partial-basic type buffer. Subsequently, and upon performing a write of the data items to the mass storage, the initial data classifier reads each data item from the corresponding type buffer and for each data item of a structured data type, orders the data of the data items into one or more data block groups wherein each data block group corresponds to a basic unit of storage and writes the one or more data block groups of each structured data type into a corresponding data type area of the storage space. For each data item of the full-basic unit type and of the partial-basic unit type, the topological data classifier re-executes the topological classification of each data item as a full-basic unit data type or as a partial-basic unit data type, orders the data of each data item of a full-basic unit data type and the data of each data item of a partial-basic unit data type into one or more corresponding full-basic unit data block groups or one or more corresponding partial-basic unit data block groups, and writes the full-basic unit data block groups and the partial-basic unit data block groups into corresponding data type areas of the storage space.
In further embodiment of the present invention, and upon writing each data item into a corresponding type buffer, the topological data formatter combines the data of a data item being written into a type buffer and the data of one or more data items residing in the type buffer to form a full-basic unit of storage space. In still further embodiments of the present invention, and upon performing a write of the data items to the mass storage, the topological data formatter returns all data items forming partial-basic unit data block groups to the corresponding type buffers for re-ordering into full-basic unit data block groups in a subsequent write to the storage space.
In a presently preferred embodiment, each basic unit of storage space is a stripe of a striped mass storage system and each stripe contains storage space for a predetermined number of data blocks. Also, the mass storage space is preferrably structured into a plurality of data partitions wherein each data partition corresponds to a data type and is used to store data of the corresponding data type. In addition, and in a presently preferred embodiment of the mass storage system, the mass storage system is a RAID technology storage system and each stripe further includes at least one data block for storing data recovery information.
In the presently preferred implementation, the file system is implemented as a log-based, quick recovery file system with a kernel based CIFS network stack and supports NFS operations in a second mode, but modified according to the present invention to provide highly available access to the data in the file system. The file system provides protection at the disk level against the loss of a disk unit through the use of RAID technology. When a disk drive is lost, the RAID mechanism provides the mechanism to rebuild the data onto a replacement drive and provides access to the data when operating without the lost disk drive. The file system further provides protection against the loss of a storage processor by preserving all data changes that network clients make to the file system by means of a data reflection feature wherein data changes stored in memory on one storage processor are preserved in the event of the hardware or software failure of that storage processor. The reflection of in-core data changes to the file system is achieved through an inter-storage processor communication system whereby data changes to the file system communicated by clients on one storage processor and using either NFS or CIFS are reflected and acknowledged as received by the other storage processor before an acknowledgment is returned to the network client storing the data. This insures that a copy of the data change is captured on the alternate storage processor in the event of failure on the original storage processor and, if and when failure occurs, the changes are applied to the file system after it has failed over to the alternate storage processor. As will be described, this reflection mechanism is built on top of underlying file system recovery mechanisms and utilizes the underlying recovery mechanisms to correct the file system before proceeding with recovery of the file system.
As described, therefore, a HAN File Server 10 of the present invention is comprised of a cluster of hierarichal and peer domains, that is, nodes or sub-systems, wherein each domain performs one or more tasks or functions of the file server and includes fault handling mechanisms. For example, the HAN File Server 10 is comprised of three hierarchical Domains 10A, 10 and 10C comprising, respectively, Networks 34N, Control/Processor Sub-System 14 and Storage Sub-System 12, which perform separate and complementary functions of the file server. That is, Domain 10A provides client/server communications between Clients 34 and the HAN File Server 10, Domain 10B, that is, Control/Processor Sub-System 14, supports the client/server communications of Domain 10A and supports high level file system transactions, and Domain 10C, that is, Storage Sub-System 12, supports the file systems of the clients. Control/Processor Sub-System 14, in turn, is comprised of two peer Domains 10D and 10E, that is, Blades 14A and 14B, which perform parallel functions, in particular client/server communications functions and higher and lower level file system operations, thereby sharing the client communications and file operations task loads. As will be described in detail in following descriptions, the domains comprising Blades 14A and 14B also include independently functioning fault handling mechanisms providing fault handling and support for client/server communications, inter-Blade 14 communications, high level file system functions, and low level file system functions executed in Storage Sub-System 12. Each Blade 14, in turn, is comprised to two hierarchical Domains 10F and 10G, based on Processing Units 36A and 36B, that perform separate but complementary functions that together comprise the functions of Blades 14A and 14B. As will be described, one or Processing Units 36 forms upper Domain 10F providing high level file operations and client/server communications with fault handling mechanisms for both functions. The other of Processing Units 36 forms lower Domain 10G providing lower level file operations and inter-Blade 14 communications, with independently operating fault handling mechanisms operating in support of both functions and of the server functions and fault handling mechanisms of the upper Domain 10F. Finally, Storage Sub-System 12 is similarly comprised of a lower Domain 10H, which comprises Disk Drives 18, that is, the storage elements of the server, and indirectly supports the RAID mechanisms supported by Domains 10E of Blades 14, and peer upper Domains 101 and 10J, which include Storage Loop Modules 20A and 20B which support communications between Domains 10D and 10E and Domain 10H.
2. Personal Computer Compatibility Sub-System of a Blade 14 ICH 38E, Super I/O 38L and VGA 38M together comprise a Personal Computer (PC) compatibility subsystem providing PC functions and services for the HAN File Server 10 for purposes of local control and display functions. For these purposes, ICH 38E, as will be understood by those of ordinary skill in the arts, provides IDE controller functions, an IO APIC, 82C59 based timers and a real time clock. Super IO 38L, in turn, may be, for example, a Standard Microsystems Device LPC47B27x and provides an 8042 keyboard/mouse controller, a 2.88 MB super IO floppy disk controller and dual full function serial ports while VGA 38M may be, for example, is a Cirrus Logic 64-bit VisualMedia® Accelerator CL-GD5446-QC supporting a 1 MB frame buffer memory.
In FE BusSys 38P, and as described above, ICH 38E includes a PCI Port 38Ef and, as shown, PCI Port 38Ef is bidirectionally to a Processor to Processor Bridge Unit (P-P Bridge) 38S which may be comprised, for example, of an Intel 21152 supporting a bi-directional 32 bit 33 MHz Front-End PCI bus segment. The Front-End PCI bus segment, in turn, is connected to a set of bi-directional Network Devices (NETDEVs) 38T connecting to Networks 34 and which may be, for example, Intel 82559 10/100 Ethernet controller devices. It will be understood, as described previously, that Networks 34 may be may be comprised, for example, of local area networks (LANs), wide area networks (WANs), direct processor connections or buses, fiber optic links, or any combination thereof, and that NETDEVs 38T will be selected accordingly.
As described, the third component of the HAN File Server 10 file mechanisms is comprised of mirroring mechanisms that provide protection against the loss of data resulting from the loss of any HAN File Server 10 component. As illustrated in FIG. 3, the mirroring mechanisms include, for each Blade 14, a Cache Mirror Mechanism (CMirror) 54C residing in the BEP 44B of the Blade 14 and a Log Mirror Mechanism (LMirror) 54L residing in the BEP 40B of the opposite, peer Blade 14. CMirror 54M is a continuous operating cache mirroring mechanism communicating with WCache 50C of JFile 50 through Message 42. Log 50L, in turn, is mirrored on demand by the LMirror 54L residing in the BEP 44B of the peer Blade 14, communicating with the corresponding LogM 50M through the path including Message 42, BE BusSys 38O and Compute Blade Bus 30, so that all data changes to the file systems through one of Blades 14A or 14B are reflected to the other of Blades 14A and 14B before being acknowledged to the client. In this regard, and in the presently preferred embodiment, the mirroring of a Log 50L is performed during the processing of each file system transaction, so that the latency of the transaction log mirroring is masked to the extent possible by the execution of the actual file system transaction. Lastly, it will be understood that the Disk Drive 18 file system, control, monitoring and data recovery/reconstruction functions supported.and provided by RAIDF 46F are additionally a part of the HAN File Server 10 data protection mechanisms, using data mirroring methods internal to Storage Sub-System 12.
As will be described further in following discussions, these mirroring mechanisms therefore support a number of alternative methods for dealing with a failure in a Blade 14, depending upon the type of failure. For example, in the event of a failure of one Blade 14 the surviving Blade 14 may read the stored file transactions stored in its LMirror 54L back to the failed Blade 14 when the failed Blade 14 is restored to operation, whereupon any lost file transactions may be re-executed and restored by the restored Blade 14. In other methods, and as will be described further with regard to Network 34 fail-over mechanisms of the Blades 14, file transactions directed to the failed Blade 14 may be redirected to the surviving Blade 14 through the either the Blade Bus 30 path between the Blades 14 or by redirection of the clients to the surviving Blade 14 by means of the Network 34 fail-over mechanisms of the Blades 14. The surviving Blade 14 will thereby assume execution of file transactions directed to the failed Blade 14. As described below, the surviving Blade 14 may, as part of this operation, either re-execute and and recover any lost file transactions of the failed Blade 14 by re-executing the file transactions from the failed Blade 14 that are stored in its LMirror 54L, or may read the file transactions back to the failed Blade 14 after the failed Blade 14 is restored to operation.surviving re-execute the file transactions residing in the LMirror 54L in the surviving Blade 14 that have been mirrored from the failed Blade 14, thereby recreating the state of the file system on the failed Blade 14 at the time of the failure, so that no data is lost from the failed Blade 14 for acknowledged transactions.
NETBIOS—a Microsoft/IBM/Intel protocol used by PC clients to access remote resources. One of the key features of this protocol is to resolve resource names into transport addresses wherein a resource is a component of a UNC name which is used by the client to identify the share, that is, a resource path, wherein in the HAN File Server 10 the resource represents the file server. NETBIOS also provides CIFS 62 packet framing, and the HAN File Server 10 uses NETBIOS over TCP/IP as defined in RFC1001 and RFC1002;
It must be noted with regard to IP Takeover operations as described above that the CFail 66 mechanisms of a HAN File Server 10 do not attempt to identify the location or cause of a connection between Networks 34 and Blades 14. Each CFail 66 instead assumes that the failure has occurred in the Port 34P interface of the opposite Blade 14 and initiates an IP Takeover operation accordingly, so that IP Takeover operations for a given communications path may be executed by Blades 14A and 14B concurrently. Concurrent IP Takeover operations by Blades 14A and 14B will not conflict, however, in the present invention. That is, and for example, if the IP Takeover operations are a result of a failure in a Port 34P interface of one of Blades 14A and 14B or in a Network 34 link to one of Blades 14A and 14B, the CFail 66 of the Blade 14 in which the failure is associated will not be able to communicate its ARP Response 66R to the Clients 34C connected through that Port 34P or Network 34 link. As a consequence, the CFail 66 of the Blade 14 associated with the failure will be unable to redirect the corresponding Client 34C traffic to its Blade 14. The CFail 66 of the opposite Blade 14, however, that is, of the Blade 14 not associated with the failure, will succeed in transmitting its ARP Response 66R to the Clients 34C associated with the failed path and thereby in redirectingthe corresponding Client 34C traffic to its Blade 14. In the event of a failure arising from a partition in the network, both Port 34P interfaces may “bridge” the network partition through the Blade Bus 30 communication path between Blades 14A and 14B, as will be described below, so that, as a result, all Clients 34C will be able to communicate with either of Blades 14A and 14B.
In the event of a failure of the Blade Bus 30 communication path, BMonitor 66B will read Blade Routing Table (BRT) 48P, in which is stored information regarding the available communicating routing paths between Blades 14A and 14B. The path information stored therein will, for example, include routing information for communications through Blade Bus 30, but also routing information for the available Networks 34 paths between the Blades 14A and 14B. It will be noted that BRT 48B may be stored in association with CFail 66 but, as shown in FIG. 3, in the presently preferred embodiments of Blades 14 BRT 48B resides in association with Network 48 as the routing path information relevant to Networks 34 is readily available and accessible to Network 48 in the normal operations of Network 48, such as in constructing CRT 48A. BMONITOR 66B will read the routing information concerning the available communications paths between the Blades 14, excluding the Blade Bus 30 path becuase of the failure of this path, and will select an available Network 34 path between the Networks 48 of the Blades 14 to be used in replacement or substitution for the Blade Bus 30 path. In this regard, it must be noted that BMONITOR 66B modifies the contents of BRT 48B during all IP Takeover operations in the same manner and currently with PM 66M's modification of the CREs 48E of CRT 48A to indicate non-functioning Network 34 paths between Blades 14, so that the replacement path for the Blade Bus 30 path is selected from only functioning Network 34 paths.
It must also be noted that the communications failure handling mechanisms of a HAN File Server 10 operate separately and independently of one another, thus again avoiding the use of complex mechanisms and operations to coordinate, synchronize and manage potentially conflicting fault management operations, but cooperatively in handling multiple sources of failure or multiple failures. For example, the operations executed by the CFail 66 Networks 34 failure mechanisms, that is, the CMonitor 66C related mechansisms, are executed independently of the operations executed by the CFail 66 Blade Bus 30 failure mechanisms, that is, the BMonitor 66B related mechansisms, but are executed in a functionally cooperative manner to maintain communications between the Clients 34C and Blades 14 and between Blades 14. Communications are maintained regardless of the sources of the failures or sequence of failures, so long as there is a single functioning Networks 34 path between Blades 14 and to each Client 34C that are executed in the event of a Blade Bus 30 path failure.
Referring to FIG. 4A, the present exemplary implementation of a Storage Sub-System 12 includes Disk Drives 18A, 18B, 18C, 18D and 16E wherein Disk Drives 18A through 18D are employed to store information, that is, various types of data, while Disk Drive 18E is used to store data recovery information relating to the data stored in Disk Drives 18A through 18D. The storage space on Disk Drives 18 is organized into segments of a selected size such as 512 bytes, 744 byes, 2048 byes, or 4098 bytes, and so on, which are generally but not necessarily of equal size, and data is stored on Disk Drives 18 in blocks, illustrated, for example, as Data Blocks (DBs) 68A through 68 n, each of which may contain data or data recovery information relating to the data. Each DB 68 occupies a segment of the disk drive storage space and may contain a number of bytes of data up to the size of a segment of storage space and a given body of data, hereafter referred to as a data item, may be comprised of or occupy one or more DBs 68.
As illustrated in FIG. 4A, the segments of storage space in Disk Drives 18 and thus the storage of DBs 68 in Disk Drives 18 are organized and structured as “stripes” across Disk Drives 18. In “striping”, DBs 68 are written into Disk Drives 18 with each sequential DB 68 being located on a different sequential one of Disk Drives 18, with the sequence of DBs 68 and Disk Drives 18 being repeated as necessary to store a given data item. Therefore, and as illustrated in the present example, DBs 68DA, 68DB, 68DC and 68DC may comprise a first Stripe 70A wherein DB 68A may be located on Disk Drive 18A, DB 68B on Disk Drive 18B, DB 68C on Disk 18C, and DB 68D on Disk Drive 18D. The sequences then repeat with DBs 68E, 68F, 68G and 68H comprising a Stripe 70B with DB 68E on Disk Drive 18A, DB 68F on Disk Drive 18B, DB 68G on Disk Drive 18C, DB 68H on Disk 18D, DB 681 on Disk Drive 18A, and so on. It will therefore be apparent that in the present exemplary embodiment of a mass storage system, the “length” of each Stripe 70 across Disk Drives 18, that is, the number of DBs 68 in each Stripe 70, will be equal to the number of Disk Drives 18 assigned and allocated to store data.
As also illustrated in FIG. 4B, the mass storage functions and mechanisms further include a Demand Paging and Memory Management Facility (DPMM) 78. As is usual in such systems and as is well understood in the arts, DPPM 78 operates to relate and translate data read and write logical addresses generated by the application and operating systems programs into the corresponding physical addresses of the data in Disk Drives 18. The physical addresses provided by DPPM 78 will typically include an identification of the PART 72 and Disk Drive 18 in which the data resides. The physical addresses will also include information allowing the data to be located on the Disk Drives 18, such as the physical location in a Disk Drive 18 of the DB 68 containing the start of the referenced data and the number of DBs 68 occupied by the referenced data.
In this regard, and with regard to the present invention as described below, it must be noted that a body or item of data that is referenced in a read or write request may reside in one or more Stripes 70 or one or more partial Stripes 70 or any combination thereof and may reside, for example, in a single DB 68, in a contiguous group of DBs 68, in non-contiguous DBs 68 or in non-contiguous groups of DBs 68, or any combination thereof. There are a number of methods and mechanisms in common use in file systems to track, chain, link or otherwise relate and identify the physical locations on disks of the DBs 68 comprising a given file or body of data, any of which may be selected and implemented in the system of the present invention. As such methods and mechanisms are well known and understood by those of ordinary skill in the arts, these methods and mechanisms for tracking, chaining, linking or otherwise relating and identifying the physical locations on disks of the DBs 68 comprising a given file or body of data will not be discussed in further detail herein and it will be assumed that DPPM 78 embodies such a mechanism as necessary.
For purposes of illustration of a typical logical to physical address translation mechanism and of the present invention, however, it is assumed for purposes of the following description that Disk Drives 18 are provided with a sufficient degree of “intelligence” to relate a logical data item identification, such as a file name, offset into a file and length of data referenced, to the tracks, sectors and segments of the drive containing the Data Blocks 68 of the identified item. It is also assumed that Disk Drives 18 include sufficient “intelligence” to perform certain disk management functions, such as tracking the amount of storage capacity in use, freeing segments containing deleted DBs 68 and informing DPPM 78 whether there is sufficient remaining capacity to store a given data item.
As illustrated in FIG. 4B, DPPM 78 maintains an Address Translation Table (ATT) 80 storing the addressing information necessary to translate logical to physical addresses. It will be understood by those of ordinary skill in the arts that DPPM 78 may, for example, maintain translation lookaside buffers that operate as a cache mechanism to store the most frequently used or most recently used previously translated addresses, thereby avoiding the calculation operations necessary to translate a logical address to a physical address upon each reference. As will also be understood by those of ordinary skill in the arts, DPPM 78 will obtain the initial information necessary to construct ATT 80 and the address translation entries stored therein, which will be described below, from the information stored in DAT 74T, such as storage space topological information defining the sizes of DBs 68, the allocation of the storage space in Disk Drives 18 among Data Partition (Parts) 72 and the physical starting address location and size, that is, number of DBs 68, of each Stripe 70 in PARTs 72.
ATT 80 is represented in FIG. 4B as storing a Data Item Entry (DIE) 82 for each data item stored in Disk Drives 18 wherein a data item is comprised of one or more Data Blocks 68 that are related, for example, by containing related information or by being written into Disk Drives 18 as an entity or group. Each DIE 82 corresponds to a logical identification of a corresponding data item and includes one or more Data Address Translation Information (DATI) 84 blocks containing the information necessary for the logical to physical address translation of each read or write reference to a data item stored in Disk Drives 18, and possibly data recovery address translation information relating the corresponding logical to physical address translation information for the corresponding data recovery information. As represented in FIG. 4B, each DATI 84 may include a Data Partition Identifier (PartID) 86 identifying the PART 72 that the data item resides in, a Start 90S identifying the DB 68 at which the data item begins and Length Information (LI) 90L to identify the number of DBs 68 in the data item. Each DATI 84 may also include, from DAT 74T, may include a Disk Drive Identification (DDI) 88 identifying the particular Disk Drive 18 that at least the first DB 68 of the data item resides in. As described above, DPPM 78 will include the mechanisms necessary to tracking, chaining, linking or otherwise relating and identifying the physical locations on disks of the DBs 68 comprising a given file or body of data, even if the DBs 68 comprising the file or body of data are not contiguously located in Disk Drives 18. Depending upon the method used, and as will understood by those of ordinary skill in the relevant arts, this information may reside in the DBs 68 or in the DATI 84 blocks of each DIE 82, and need not be discussed further herein. Lastly with respect to ATT 80, it should be noted that information described herein above as stored in either DAT 74T and in ATT 80 may be stored in a single, unified ATT 80, rather than between DAT 74T and ATT 80.
Next considering the physical addresses generated by DPPM 78, and depending upon the degree of intelligence in Disk Drives 18, each Physical Address 92 may include a Data Item Identification (DII) 94, a Disk Drive Identification (DDI) 96, an identification of a Data Partition Identification (PartID) 98 and a Data Block Identification (DBI) 100. DPPM 78 will therefore access a data item containing a plurality of DBs 68 by generating a sequence of Physical Addresses 92, one for each DB 68 in the data item identified by the logical address, starting with the first DB 68 of the data item and proceeding sequentially through the DBs 68 for the identified length of the data item. It will be understood by those of ordinary skill in the relevant arts that the form and contents Physical Addresses 92 and the generation of Physical Addresses 92 to locate the DBs 68 of a data item will depend upon, for example, the capabilities and operation of Disk Drives 18 and the scheme by which DBs 68 are stored on Disk Drives 18. That is, in some implementations Disk Drives 18 may be provided with a DII 94 and a data item length, that is, number of DBs 68, and will sequentially locate and access the successive DBs 68 of the identified data item. In other embodiments of Disk Drives 18, it may be necessary to generate a Physical Address 92 for each DB 68 and to issue a sequence of read or write commands. The requirement for and the form and content of Physical Addresses 92 will also depend upon the scheme by which the DBs 68 are stored on the Disk Drives 18, that is, the method and pattern of striping and whether the DBs 68 of a given data item are always stored contiguously or may be stored non-contiguously. In addition, the identity and physical locations of the DBs 68 comprising a data item can also be identified and determined in a number of alternate ways that will be known and understood by those of ordinary skill in the relevant arts. For example, the logical to physical address translation described just above assumes a sufficient degree of “intelligence” in each Disk Drive 18 to identify the track and sector locations in a Disk Drive 18 of the DBs 68 of an identified data item. In other systems, the DATIs 84 may also include, for example, the track, sector and segment identifications for the Disk Drives 18 in which the Data Block (DBs) 68 reside, or information for generating the track, sector and segment identifications, as will the Physical Addresses 92. Again, the generation of physical addresses for such systems is well known and understood by those of ordinary skill in the relevant arts and will not therefore be discussed in detail.
Now considering the present invention in detail, it has been described above that, according to the present invention, the storage space available in Disk Drives 18 is organized into one more data partitions PARTs 72, wherein, and for example, a PART 72 may be comprised of one or multiple Disk Drives 18 or of a part of a Disk Drive 18. Each PART 72 is used as a logical storage device or area and each of PARTs 72 is separately identifiable and addressable to operate as logical devices or storage areas for reading, writing and storing data. This structuring and organization of the storage space in Disk Drives 18 is represented in FIG. 4A, wherein the storage space of Disk Drives 18 is represented as partitioned or allocated into a plurality of PARTs 72, represented as PARTs 72A, 72B, and so on through PART 72n and wherein the physical storage areas within each PART 72 is structured as one or more Stripes 70.
As illustrated in FIG. 4B, Topological Data Formatter 102 is connected between, for example, JFile 50 and RAIDF 46F, includes a Write Data Buffer (WBuff) 104 and a Data Classifier (DClass) 106 wherein WBuff 104 may, for example, be implemented in the Memory 38A of each Blade 14 and DClass 106 may, for example, be implemented in the BEP 44B of each Blade 14 and in association with the RAID 46 functions therein.
As illustrated in FIG. 4B, DClass 106 and WBuff 104 in conjunction with DPPM 78 to classify and buffer data to be written into Disk Drives 18. As described below, DClass 106 and WBuff 104 operate to organize or structure data to be written into Disk Drives 18 optimally with respect to the storage space topology of Disk Drives 18 and the disk processing methods or algorithms of the selected RAID methodology implemented therein. In this regard, and as illustrated in FIG. 4B, WBuff 104 is partitioned into a plurality of Type Buffers (TBuffs) 108A through 108 n wherein each TBuff 108 corresponds to a PART 72, and thus to a type or category of data, and each TBuff 108 is used to store a corresponding type of data before that data is written into Disk Drives 18.
Subsequently, at the next time that the buffered data in WBuff 104 is to be written into Disk Drives 18, the Data 10D contents of each “structured” TBuff 108 are read from the TBuffs 108 and are ordered into one or more “full-stripe” Data Block Groups (DBGs) 114 wherein each DBG 114 contains one or more DBs 68 of “structured” Data 110D. The “full-stripe” DBGs 114 forming are written contiguously into the corresponding “structured” PARTs 72 in one or more full Stripe 70 writes, with the Data 110D contents preferably being sequentially ordered in the writes if such ordering is advantageous of possible within the characteristics of the data.
According to the present invention, and as indicated in FIG. 4B, IClass 112 identifies and classifies such Data Items 110 as containing data of a type or types, such as “general” data, that is to be topologically classified or categorized, and transfers such Data Items 110 to a Topological Classifier (TClass) 116. TClass 116, in turn, identifies from the Write Data Item 110 the Data Item Identification (DII) 94 of the file or other data structure into which the Data 110D is to be written, the starting location within the file or data structure at which the Data 110D is to be written, and the size, that is, number of DBs 68, of the Data 110D that is to be written. From the information in ATT 80 for that Write Data Item 110, TClass 116 determines the DDI 88 and PartID 86 identifying the particular Disk Drive 18 and PART 72 that the first DB 68 of the data item resides in, a Start 90S identifying the DB 68 at which the data item begins and Length Information (LI) 90L to identify the number of DBs 68 in the data item. It will be understood that this information from ATT 80 may also include, for example, linking or chaining information, if such information is necessary to locate the relevant DBs 68 of the data item in Disk Drives 18. Finally, TClass 116 may also access DAT 74T to obtain relevant striping pattern information, such as the number DBs 68 in each Stripe 70 of the appropriate PART 72 and the size of the DBs 68.
TClass 116 will determine, for each Write Data Item 110 that is to be topologically categorized, the topological relationship of the Data 110D and the topological organization of storage space in the Disk Drives 18. That is, TClass 116 will compare the starting point in Disk Drives 18 and size of the file or data structure identified by the corresponding DII 94, the location at which the Data 110D is to be written, the size of the Data 10D, the size and number of DBs 68 in a Stripe 70 and starting points of Stripes 70 in a PART 72, to determine the alignment of the Data 110D with the striping pattern. From this comparison, TClass 116 will determine an initial classification or categorization of a Write Data Item 110 as representing “full stripe” data or “partial-stripe” data, that is, whether the Data 110D contains one or more full Stripes 70 of data, with a starting point falling on the starting boundary of a Stripe 70, or contains one or more partial Stripes 70 of data or has a starting point not falling on the starting boundary of a Stripe 70.
At the next time that the buffered data in WBuff 104 is to be written into Disk Drives 18, DClass 106 will read the Write Data Items 110 from the “full-stripe” and “ partial-stripe” TBuffs 108 and TClass 116 will re-execute the categorization of each Write Data Item 110 residing therein. If the initial categorization of a Write Data Item 110 as a “full-stripe” Write Data Item 110 is found to be correct, DClass 106 will order the Data 110D of the Write Data Item 110 into one or more DBGs 114 with other such Datas 110D. DClass 106 will then write the DBGs 114 containing “full-stripe” Datas 110D into the “full-stripe” PART 72. As a consequence, each Write Data Item 110 that has been confirmed as correctly categorized as “full-stripe” Write Data Items 110 will be written to the appropriate location in the “full-stripe” PART 72 one or more full stripe writes, thereby avoiding the usual read-modify-write operation and significantly enhancing the data transfer rate.
If the initial categorization of a Write Data Item 110 as a “full-stripe” Write Data Item 110 is found to be incorrect, for example, as a result of previous writes of topologically related Write Data Items 110 to Disk Drives 18, DClass 106 will re-categorize the Write Data Item 110 as a “partial-stripe” data item. DClass 106 may then re-write the re-categorized “partial-stripe” Write Data Items 110 back into the “partial-stripe” TBuff 108 for re-examination and possible combination with other accumulated “partial-stripe” Write Data Items 110 into one or more “full-stripe” Write Data Items 110, to be subsequently treated as described below. Alternately, DClass 106 may write the re-categorized “partial-stripe” Write Data Items 110 to the appropriate location in the “partial-stripe” PART 72 in Disk Drives 18 in one or more “partial-stripe” DBGs 114. DClass 108 may also re-write the re-categorized “partial-stripe” Write Data Items 110 to the “partial-stripe” TBuff 108 to be held for a subsequent re-evaluation and possible combination with other “partial-stripe” Write Data Items 110 into “full-stripe” Write Data Items 110 during a subsequent write to Disk Drives 18 by DClass 106.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6128717 *Jan 20, 1998Oct 3, 2000Quantum CorporationMethod and apparatus for storage application programming interface for digital mass storage and retrieval based upon data object type or size and characteristics of the data storage deviceUS6526406 *Jun 2, 2000Feb 25, 2003Kawasaki Steel Systems R & D CorporationDatabase access system to deliver and store information* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6788575 *Sep 23, 2003Sep 7, 2004Renesas Technology Corp.Nonvolatile memoryUS6868032Aug 10, 2004Mar 15, 2005Renesas Technology Corp.Nonvolatile memoryUS7012845Feb 9, 2005Mar 14, 2006Renesas Technology Corp.Nonvolatile memory with control circuit adapted to distinguish between command signal interface specifications and having an error correction functionUS7197598 *Jul 18, 2003Mar 27, 2007Electronics And Telecommunications Research InstituteApparatus and method for file level stripingUS7230859Jan 12, 2006Jun 12, 2007Renesas Technology Corp.Nonvolatile memoryUS7254016May 25, 2004Aug 7, 2007Emc CorporationData storage system with improved serviceability featuresUS7350031 *Jun 28, 2005Mar 25, 2008Intel CorporationMechanism for automatic backups in a mobile systemUS7366034May 8, 2007Apr 29, 2008Renesas Technology Corp.Nonvolatile memoryUS7389411 *Aug 29, 2003Jun 17, 2008Sun Microsystems, Inc.Secure transfer of host identitiesUS7409493 *Oct 2, 2006Aug 5, 2008Micron Technology, Inc.Top/bottom symmetrical protection scheme for flashUS7525852Mar 13, 2008Apr 28, 2009Renesas Technology Corp.Nonvolatile memoryUS7533117 *Aug 9, 2004May 12, 2009William Marsh Rice UniversityComponent-based adaptation system and methodUS7574560Jan 3, 2006Aug 11, 2009Emc CorporationMethods, systems, and computer program products for dynamic mapping of logical units in a redundant array of inexpensive disks (RAID) environmentUS7603529Mar 22, 2006Oct 13, 2009Emc CorporationMethods, systems, and computer program products for mapped logical unit (MLU) replications, storage, and retrieval in a redundant array of inexpensive disks (RAID) environmentUS7676587Dec 14, 2004Mar 9, 2010Emc CorporationDistributed IP trunking and server clustering for sharing of an IP server address among IP serversUS7779088 *Jan 29, 2008Aug 17, 2010International Business Machines CorporationAutonomic learning method to load balance output transfers of two peer nodesUS7817480Mar 23, 2009Oct 19, 2010Renesas Electronics CorporationNonvolatile memoryUS7890504Dec 21, 2007Feb 15, 2011Netapp, Inc.Using the LUN type for storage allocationUS7933158Oct 1, 2010Apr 26, 2011Renesas Electronics CorporationNonvolatile memoryUS7934052Apr 8, 2008Apr 26, 2011Pliant Technology, Inc.System and method for performing host initiated mass storage commands using a hierarchy of data structuresUS8086603Feb 7, 2011Dec 27, 2011Netapp, Inc.Using LUN type for storage allocationUS8223563Apr 13, 2011Jul 17, 2012Renesas Electronics CorporationNonvolatile memoryUS8245101Apr 8, 2008Aug 14, 2012Sandisk Enterprise Ip LlcPatrol function used in flash storage controller to detect data errorsUS8365041Mar 17, 2010Jan 29, 2013Sandisk Enterprise Ip LlcMLC self-raid flash data protection schemeUS8386700Nov 29, 2011Feb 26, 2013Sandisk Enterprise Ip LlcFlash memory controller garbage collection operations performed independently in multiple flash memory groupsUS8397011Oct 5, 2007Mar 12, 2013Joseph AshwoodScalable mass data storage deviceUS8473814Jun 27, 2012Jun 25, 2013Sandisk Enterprise Ip LlcMLC self-RAID flash data protection schemeUS8484533Jun 27, 2012Jul 9, 2013Sandisk Enterprise Ip LlcMLC self-RAID flash data protection schemeUS8484534Jun 27, 2012Jul 9, 2013Sandisk Enterprise IP LLC.MLC self-RAID flash data protection schemeUS8533384Apr 8, 2008Sep 10, 2013Sandisk Enterprise Ip LlcFlash memory controller garbage collection operations performed independently in multiple flash memory groupsUS8621137Apr 8, 2008Dec 31, 2013Sandisk Enterprise Ip LlcMetadata rebuild in a flash memory controller following a loss of powerUS8621138Apr 8, 2008Dec 31, 2013Sandisk Enterprise Ip LlcFlash storage controller execute loopUS8738841Apr 8, 2008May 27, 2014Sandisk Enterprise IP LLC.Flash memory controller and system including data pipelines incorporating multiple buffersUS8751755Apr 8, 2008Jun 10, 2014Sandisk Enterprise Ip LlcMass storage controller volatile memory containing metadata related to flash memory storageUS8762620Apr 8, 2008Jun 24, 2014Sandisk Enterprise Ip LlcMultiprocessor storage controllerUS8775717Apr 8, 2008Jul 8, 2014Sandisk Enterprise Ip LlcStorage controller for flash memory including a crossbar switch connecting a plurality of processors with a plurality of internal memoriesUS8793543Aug 31, 2012Jul 29, 2014Sandisk Enterprise Ip LlcAdaptive read comparison signal generation for memory systemsUS8891303Jun 6, 2014Nov 18, 2014Sandisk Technologies Inc.Method and system for dynamic word line based configuration of a three-dimensional memory deviceUS8904229Jun 29, 2012Dec 2, 2014Emc CorporationOnline recovery of a file system experiencing failure of redundant logical storage storing a single point of failureUS8909982Oct 31, 2011Dec 9, 2014Sandisk Enterprise Ip LlcSystem and method for detecting copyback programming problemsUS8910020Oct 31, 2011Dec 9, 2014Sandisk Enterprise Ip LlcIntelligent bit recovery for flash memoryUS8924815Nov 16, 2012Dec 30, 2014Sandisk Enterprise Ip LlcSystems, methods and devices for decoding codewords having multiple parity segmentsUS8938658Aug 31, 2012Jan 20, 2015Sandisk Enterprise Ip LlcStatistical read comparison signal generation for memory systemsUS8954822Nov 16, 2012Feb 10, 2015Sandisk Enterprise Ip LlcData encoder and decoder using memory-specific parity-check matrixUS8959282May 10, 2013Feb 17, 2015Sandisk Enterprise Ip LlcFlash storage controller execute loopUS8959283Dec 20, 2013Feb 17, 2015Sandisk Enterprise Ip LlcFlash storage controller execute loopUS9003264Mar 15, 2013Apr 7, 2015Sandisk Enterprise Ip LlcSystems, methods, and devices for multi-dimensional flash RAID data protectionUS9009576Mar 15, 2013Apr 14, 2015Sandisk Enterprise Ip LlcAdaptive LLR based on syndrome weightUS9043517Sep 24, 2013May 26, 2015Sandisk Enterprise Ip LlcMultipass programming in buffers implemented in non-volatile data storage systemsUS9048876Nov 16, 2012Jun 2, 2015Sandisk Enterprise Ip LlcSystems, methods and devices for multi-tiered error correctionUS9058289Aug 31, 2012Jun 16, 2015Sandisk Enterprise Ip LlcSoft information generation for memory systemsUS9069682Jun 29, 2012Jun 30, 2015Emc CorporationAccelerating file system recovery by storing file system metadata on fast persistent storage during file system recoveryUS9070481Jun 6, 2014Jun 30, 2015Sandisk Technologies Inc.Internal current measurement for age measurementsUS9081753 *Mar 14, 2013Jul 14, 2015Microsoft Technology Licensing, LlcVirtual disk recovery and redistributionUS9092350Sep 11, 2013Jul 28, 2015Sandisk Enterprise Ip LlcDetection and handling of unbalanced errors in interleaved codewordsUS9092370 *Dec 19, 2013Jul 28, 2015Sandisk Enterprise Ip LlcPower failure tolerant cryptographic eraseUS9093160Jun 6, 2014Jul 28, 2015Sandisk Technologies Inc.Methods and systems for staggered memory operationsUS9122636Dec 19, 2013Sep 1, 2015Sandisk Enterprise Ip LlcHard power fail architectureUS9129665Dec 19, 2013Sep 8, 2015Sandisk Enterprise Ip LlcDynamic brownout adjustment in a storage deviceUS9136877Aug 20, 2013Sep 15, 2015Sandisk Enterprise Ip LlcSyndrome layered decoding for LDPC codesUS9146928Dec 31, 2012Sep 29, 2015Emc CorporationTechniques for storing metadata of a filesystem in persistent memoryUS9152555Nov 15, 2013Oct 6, 2015Sandisk Enterprise IP LLC.Data management with modular erase in a data storage systemUS9152556Dec 11, 2013Oct 6, 2015Sandisk Enterprise Ip LlcMetadata rebuild in a flash memory controller following a loss of powerUS9158349Dec 19, 2013Oct 13, 2015Sandisk Enterprise Ip LlcSystem and method for heat dissipationUS9158677May 3, 2013Oct 13, 2015Sandisk Enterprise Ip LlcFlash storage controller execute loopUS9159437Jun 21, 2013Oct 13, 2015Sandisk Enterprise IP LLC.Device and method for resolving an LM flag issueUS9170941Nov 15, 2013Oct 27, 2015Sandisk Enterprises IP LLCData hardening in a storage systemUS9214198Jan 16, 2015Dec 15, 2015Sandisk Enterprise Ip LlcContinuous capacitor health monitoring and power supply systemUS9214965Nov 8, 2013Dec 15, 2015Sandisk Enterprise Ip LlcMethod and system for improving data integrity in non-volatile storageUS9235245Dec 19, 2013Jan 12, 2016Sandisk Enterprise Ip LlcStartup performance and power isolationUS9235509Sep 17, 2013Jan 12, 2016Sandisk Enterprise Ip LlcWrite amplification reduction by delaying read access to data written during garbage collectionUS9236886Sep 17, 2013Jan 12, 2016Sandisk Enterprise Ip LlcUniversal and reconfigurable QC-LDPC encoderUS9239751Mar 15, 2013Jan 19, 2016Sandisk Enterprise Ip LlcCompressing data from multiple reads for error control management in memory systemsUS9239783May 14, 2013Jan 19, 2016Sandisk Enterprise Ip LlcMultiprocessor storage controllerUS9244763Sep 17, 2013Jan 26, 2016Sandisk Enterprise Ip LlcSystem and method for updating a reading threshold voltage based on symbol transition informationUS9244785Dec 19, 2013Jan 26, 2016Sandisk Enterprise Ip LlcSimulated power failure and data hardeningUS9250676Dec 19, 2013Feb 2, 2016Sandisk Enterprise Ip LlcPower failure architecture and verificationUS9263156Dec 19, 2013Feb 16, 2016Sandisk Enterprise Ip LlcSystem and method for adjusting trip points within a storage deviceUS9280429Dec 19, 2013Mar 8, 2016Sandisk Enterprise Ip LlcPower fail latching based on monitoring multiple power supply voltages in a storage deviceUS9298252Apr 2, 2013Mar 29, 2016SMART Storage Systems, Inc.Storage control system with power down mechanism and method of operation thereofUS9298608Dec 20, 2013Mar 29, 2016Sandisk Enterprise Ip LlcBiasing for wear leveling in storage systemsUS9323637Dec 19, 2013Apr 26, 2016Sandisk Enterprise Ip LlcPower sequencing and data hardening architectureUS9329928Nov 8, 2013May 3, 2016Sandisk Enterprise IP LLC.Bandwidth optimization in a non-volatile memory systemUS9342571 *Sep 12, 2014May 17, 2016Sumo LogicSelective structure preserving obfuscationUS9348377Apr 3, 2014May 24, 2016Sandisk Enterprise Ip LlcThermal isolation techniquesUS9361221Sep 17, 2013Jun 7, 2016Sandisk Technologies Inc.Write amplification reduction through reliable writes during garbage collectionUS9367246Aug 9, 2013Jun 14, 2016Sandisk Technologies Inc.Performance optimization of data transfer for soft information generationUS9384126Sep 24, 2013Jul 5, 2016Sandisk Technologies Inc.Methods and systems to avoid false negative results in bloom filters implemented in non-volatile data storage systemsUS9390021Jul 21, 2014Jul 12, 2016Sandisk Technologies LlcEfficient cache utilization in a tiered data structureUS9390814Aug 7, 2014Jul 12, 2016Sandisk Technologies LlcFault detection and prediction for data storage elementsUS9436831Dec 19, 2013Sep 6, 2016Sandisk Technologies LlcSecure erase in a memory deviceUS9442662Dec 20, 2013Sep 13, 2016Sandisk Technologies LlcDevice and method for managing die groupsUS9442670Aug 27, 2014Sep 13, 2016Sandisk Technologies LlcMethod and system for rebalancing data stored in flash memory devicesUS9443601Sep 8, 2014Sep 13, 2016Sandisk Technologies LlcHoldup capacitor energy harvestingUS9448743Apr 25, 2014Sep 20, 2016Sandisk Technologies LlcMass storage controller volatile memory containing metadata related to flash memory storageUS9448876Aug 7, 2014Sep 20, 2016Sandisk Technologies LlcFault detection and prediction in storage devicesUS9454420Mar 15, 2013Sep 27, 2016Sandisk Technologies LlcMethod and system of reading threshold voltage equalizationUS9454448Aug 7, 2014Sep 27, 2016Sandisk Technologies LlcFault testing in storage devicesUS9483210Oct 7, 2015Nov 1, 2016Sandisk Technologies LlcFlash storage controller execute loopUS9485851Apr 3, 2014Nov 1, 2016Sandisk Technologies LlcThermal tube assembly structuresUS9497889May 12, 2014Nov 15, 2016Sandisk Technologies LlcHeat dissipation for substrate assembliesUS9501398Mar 14, 2013Nov 22, 2016Sandisk Technologies LlcPersistent storage device with NVRAM for staging writesUS9519319Apr 3, 2014Dec 13, 2016Sandisk Technologies LlcSelf-supporting thermal tube structure for electronic assembliesUS9519577Aug 27, 2014Dec 13, 2016Sandisk Technologies LlcMethod and system for migrating data between flash memory devicesUS9520162Dec 19, 2013Dec 13, 2016Sandisk Technologies LlcDIMM device controller supervisorUS9520197Dec 19, 2013Dec 13, 2016Sandisk Technologies LlcAdaptive erase of a storage deviceUS9524235Sep 24, 2013Dec 20, 2016Sandisk Technologies LlcLocal hash value generation in non-volatile data storage systemsUS9549457Feb 12, 2014Jan 17, 2017Sandisk Technologies LlcSystem and method for redirecting airflow across an electronic assemblyUS20030037187 *Aug 12, 2002Feb 20, 2003Hinton Walter H.Method and apparatus for data storage information gatheringUS20040057316 *Sep 23, 2003Mar 25, 2004Renesas Technology Corp.Nonvolatile memoryUS20040107314 *Jul 18, 2003Jun 3, 2004Chang-Soo KimApparatus and method for file-level stripingUS20040158582 *Oct 31, 2003Aug 12, 2004Shuichi TakagiMethod and apparatus for synchronously transferring data from a local storage medium to a remote storage medium, and method and system for managing transfer of data from a source storage medium to a repository storage mediumUS20050007860 *Aug 10, 2004Jan 13, 2005Renesas Technology Corp.Nonvolatile memoryUS20050050356 *Aug 29, 2003Mar 3, 2005Sun Microsystems, Inc.Secure transfer of host identitiesUS20050125462 *Aug 9, 2004Jun 9, 2005Lara Eyal D.Component-based adaptation system and methodUS20050141300 *Feb 9, 2005Jun 30, 2005Renesas Technology Corp.Nonvolatile memoryUS20060114726 *Jan 12, 2006Jun 1, 2006Renesas Technology Corp.Nonvolatile memoryUS20060129695 *Dec 14, 2004Jun 15, 2006Sorin FaibishDistributed IP trunking and server clustering for sharing of an IP server address among IP serversUS20060294198 *Jun 28, 2005Dec 28, 2006Rajeev MuralidharMechanism for automatic backups in a mobile systemUS20070028036 *Oct 2, 2006Feb 1, 2007Micron Technology, Inc.Top/bottom symmetrical protection scheme for flashUS20070156957 *Jan 3, 2006Jul 5, 2007Emc CorporationMethods, systems, and computer program products for dynamic mapping of logical units in a redundant array of inexpensive disks (RAID) environmentUS20070177739 *Jan 27, 2006Aug 2, 2007Nec Laboratories America, Inc.Method and Apparatus for Distributed Data ReplicationUS20070206418 *May 8, 2007Sep 6, 2007Kenji KozakaiNonvolatile memoryUS20080040458 *Aug 14, 2006Feb 14, 2008Zimmer Vincent JNetwork file system using a subsocket partitioned operating system platformUS20080126452 *Jan 29, 2008May 29, 2008International Business Machines CorporationAutonomic learning method to load balance output transfers of two peer nodesUS20080158963 *Mar 13, 2008Jul 3, 2008Kenji KozakaiNonvolatile memoryUS20080192643 *Feb 13, 2007Aug 14, 2008International Business Machines CorporationMethod for managing shared resourcesUS20090094406 *Oct 5, 2007Apr 9, 2009Joseph AshwoodScalable mass data storage deviceUS20090164536 *Dec 21, 2007Jun 25, 2009Network Appliance, Inc.Using The LUN Type For Storage AllocationUS20090172257 *Apr 8, 2008Jul 2, 2009Pliant Technology, IncSystem and method for performing host initiated mass storage commands using a hierarchy of data structuresUS20090172258 *Apr 8, 2008Jul 2, 2009Pliant Technology, IncFlash memory controller garbage collection operations performed independently in multiple flash memory groupsUS20090172260 *Apr 8, 2008Jul 2, 2009Pliant Technology, Inc.Flash memory controller and system including data pipelines incorporating multiple buffersUS20090172261 *Apr 8, 2008Jul 2, 2009Pliant Technology, Inc.Multiprocessor storage controllerUS20090172308 *Apr 8, 2008Jul 2, 2009Pliant Technology, Inc.Storage controller for flash memory including a crossbar switch connecting a plurality of processors with a plurality of internal memoriesUS20090172499 *Apr 8, 2008Jul 2, 2009Pliant Technology, Inc.Patrol function used in flash storage controller to detect data errorsUS20090187702 *Mar 23, 2009Jul 23, 2009Renesas Technology Corp.Nonvolatile memoryUS20100169570 *Dec 31, 2008Jul 1, 2010Michael MesnierProviding differentiated I/O services within a hardware storage controllerUS20110022913 *Oct 1, 2010Jan 27, 2011Renesas Electronics CorporationNonvolatile memoryUS20110125797 *Feb 7, 2011May 26, 2011Netapp, Inc.Using lun type for storage allocationUS20140281692 *Mar 14, 2013Sep 18, 2014Microsoft CorporationVirtual Disk Recovery and RedistributionWO2009085671A2 *Dec 12, 2008Jul 9, 2009Netapp, Inc.Using the lun type for storage allocationWO2009085671A3 *Dec 12, 2008Aug 27, 2009Netapp, Inc.Using the lun type for storage allocationWO2009086357A1 *Dec 23, 2008Jul 9, 2009Pliant Technology, Inc.System and method for performing host initiated mass storage commands using a hierarchy of data structures* Cited by examinerClassifications U.S. Classification711/114, 707/999.2, 707/999.201, 707/999.202International ClassificationG06F12/00Cooperative ClassificationG06F12/1027, G06F11/1076, G06F3/0689, G06F3/064, G06F3/061, Y10S707/99953, Y10S707/99952, G06F11/2089, G06F11/1435Legal EventsDateCodeEventDescriptionOct 5, 2000ASAssignmentOwner name: EMC CORPORATION, MASSACHUSETTSFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:O CONNELL, MARK ANDREW;REEL/FRAME:011234/0458Effective date: 20000919Jul 13, 2007FPAYFee paymentYear of fee payment: 4Jul 13, 2011FPAYFee paymentYear of fee payment: 8Jul 13, 2015FPAYFee paymentYear of fee payment: 12Sep 21, 2016ASAssignmentOwner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, AS COLLATFree format text: SECURITY AGREEMENT;ASSIGNORS:ASAP SOFTWARE EXPRESS, INC.;AVENTAIL LLC;CREDANT TECHNOLOGIES, INC.;AND OTHERS;REEL/FRAME:040134/0001Effective date: 20160907Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AFree format text: SECURITY AGREEMENT;ASSIGNORS:ASAP SOFTWARE EXPRESS, INC.;AVENTAIL LLC;CREDANT TECHNOLOGIES, INC.;AND OTHERS;REEL/FRAME:040136/0001Effective date: 20160907Sep 29, 2016ASAssignmentOwner name: EMC IP HOLDING COMPANY LLC, MASSACHUSETTSFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EMC CORPORATION;REEL/FRAME:040203/0001Effective date: 20160906RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services