Source: http://www.google.com/patents/US8145598?dq=552685
Timestamp: 2015-01-28 05:01:03
Document Index: 687583065

Matched Legal Cases: ['art 403', 'art 404', 'art 403', 'art 404', 'art 403', 'art 403', 'art 403', 'art 403', 'art 403', 'art 407', 'art 403', 'art 403', 'art 403', 'art 403', 'art 404', 'arts 403', 'arts 403', 'art 403', 'art 404', 'art 403', 'art 403', 'art 404', 'arts 403']

Patent US8145598 - Methods and systems for single instance storage of asset parts - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsMethods and systems are disclosed that relate to single instance storage of asset parts utilizing a back reference count associated with each asset part. Entries in a journal associated with the asset parts reflect the intention to increment or decrement an asset part's back reference count. The journal...http://www.google.com/patents/US8145598?utm_source=gb-gplus-sharePatent US8145598 - Methods and systems for single instance storage of asset partsAdvanced Patent SearchPublication numberUS8145598 B2Publication typeGrantApplication numberUS 12/391,099Publication dateMar 27, 2012Filing dateFeb 23, 2009Priority dateFeb 23, 2009Also published asUS20100228784, WO2010096685A1Publication number12391099, 391099, US 8145598 B2, US 8145598B2, US-B2-8145598, US8145598 B2, US8145598B2InventorsPeter D. Beaman, Tuyen M. Tran, Robert S. NewsonOriginal AssigneeIron Mountain IncorporatedExport CitationBiBTeX, EndNote, RefManPatent Citations (69), Non-Patent Citations (30), Referenced by (1), Classifications (14), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetMethods and systems for single instance storage of asset partsUS 8145598 B2Abstract Methods and systems are disclosed that relate to single instance storage of asset parts utilizing a back reference count associated with each asset part. Entries in a journal associated with the asset parts reflect the intention to increment or decrement an asset part's back reference count. The journal may be used to maintain an accurate and reliable reference count for asset parts replicated across multiple disk drives in a distributed storage system, where the replication is structured to reduce the risk of data loss in the event of a disk drive failure. The journal entries may comprise generation numbers used to maintain a back reference count associated with an asset part and to verify a back reference count associated with an asset part.
BACKGROUND In computer systems where multiple disk drives are available, data may replicated and stored redundantly to reduce the risk of losing data when hardware failure occurs. The redundancy of data in such a system is intentional so that when a disk drive fails, the computer system can access the same data from the redundant disk drive. In addition to the intentional redundancy to reduce risk of data loss, unintentional redundant data may exist in a computer system. For example, multiple users of a shared system may store the same data item, or the same data item may be stored at different times. This duplication increases the size and therefore the cost of the system.
To maintain the information necessary to reconstruct the original asset, some single instance storage systems maintain forward references from the asset to its asset parts. Using these forward references, the system can identify all asset parts that make up the original asset. In addition, such systems may use backward references from an asset part to the asset, or assets, that refer to it. Using these backward references, or �back references,� the system can determine when the asset part can be safely destroyed or deleted (i.e. when the asset part has no back references to any assets).
An �asset,� as used herein, refers to one or more units of data. A single asset may correspond to data comprising what an end user application would consider to be a single file, such as a MICROSOFT Office Word� document, or an email. Assets contain application metadata and one or more asset parts. The application metadata may contain the elements that an application applies in the process of managing the asset, such as annotations or retention data. Asset parts are portions of assets. In an illustrative embodiment, an asset part contains only immutable data, such as an archival copy of a document, but in other embodiments, asset parts may contain changeable data. Typically, the end user application performs the decomposition of an asset into its asset parts. In some embodiments, additional decomposition may be performed by the data storage system, or the decomposition into asset parts by an application may be replaced by the decomposition performed by the data storage system. In other embodiments, decomposition may be performed solely by the data storage system.
FIG. 3 shows exemplary assets 400 and 401. Asset 400 has two asset parts, 403 and 404. If asset 400 is an email, for example, asset part 403 may be the body text of the email and asset part 404 may be an attachment to the email. For another example, if asset 400 is a MICROSOFT Office Word� document, asset part 403 may be the text and formatting information relating to the text, and asset part 404 may be an embedded figure in the document. In alternative embodiments, an asset may correspond to a portion of a file. Further, in alternative embodiments, more hierarchy may exist so that the asset parts themselves have child asset parts.
In the exemplary embodiment of FIG. 3, asset metadata 402 comprises status 409, which is a data field indicating the status of the asset, such as �unknown,� �pending,� �valid,� �failed,� or �destroyed.� This field is set by algorithms in the data storage subsystem to signify the status of the asset. Such an algorithm may be configured to ensure that new assets ingested into data storage system 100 are fully ingested (i.e. an asset may be considered fully ingested when all of the associated asset parts' content and metadata and the asset's content and metadata are stored replicated). In one embodiment, the asset 400 is replicated to various nodes of the data storage system to ensure redundancy, and while the replication is in progress, status 409 is �pending.� When the replication is completed, the data storage system 100 sets the status 409 to �valid� for each replica of the asset. The �pending� status has an associated time out period, and if the status is not changed to �valid� within that period, the status is instead marked �failed.� In one embodiment, increments to a back reference count associated with the asset parts referenced by an asset do not occur unless the status of the asset is �valid.�
Further, an algorithm may be configured to ensure that assets being deleted from the data storage system 100 are properly deleted (i.e. all memory locations containing the deleted asset have been overwritten and/or future access to the deleted asset is prevented). In one embodiment, the asset 400 is replicated to various nodes of the data storage system to ensure redundancy, and while the deletion is in progress, the status 409 remains �valid.� When the deletion is completed, the data storage system 100 sets status 409 to �destroyed� for each replica of the asset. In one embodiment, decrements to a back reference count associated with the asset parts referenced by an asset do not occur unless the status of the asset is �destroyed.� Further, when the status of an asset is �unknown,� �pending,� or �failed,� increments or decrements to the associated asset part's back reference count may be prevented. Using the methods disclosed herein, a particular instruction to increment or decrement an asset part's back reference count should occur only once each time the associated asset's status has made the appropriate transition (i.e. �pending� to �valid� or �valid� to �destroyed.�)
Each asset part has associated asset part metadata that may be stored with the content of the asset part or may be stored in a separate location, such as in a page within a stripe. For example, data storage system 100 may store asset part metadata 503 in a storage metadata record, such as record 30, which is one of the records among the storage metadata records 500 (or one of the records on the �page�) in stripe 15 shown in FIG. 4. The associated metadata for asset part 403 of FIG. 3, for example, may include unique identifier 410, confirmed reference count 413, confirmed generation 414, and unconfirmed generation 415. In the illustrative example of FIG. 3, the confirmed reference count 413, confirmed generation 414, and unconfirmed generation 415 are numerical values. These values are initialized to zero when the asset part is created on the data storage system and are updated according to the methods disclosed herein.
The journal entries represent an intention by the data storage system 100 to perform some action, or a record of having performed some action. For example, entry 561, �AR,� represents the intention to add a back reference from asset part 403, identified by unique identifier 410, to asset 400 identified by unique identifier 438. Thus, executing entry 561 should result in an increment of the confirmed back reference count 413 of asset part 403. Similarly, entry 567, �RR,� represents the intention to remove a back reference from asset part 403 to asset 400. Thus, executing entry 567 should result in a decrement of the confirmed back reference count 413 of asset part 403.
In the exemplary journal 502, entry 563, �CR,� represents an indication that a confirmation cycle has occurred on stripe 15. In the exemplary embodiment disclosed herein, the confirmation cycle is a process by which the data storage system 100 executes the intentions listed as entries in the journal 502. In one embodiment, confirmation cycles run periodically. Since more entries may be added to the journal while a confirmation cycle is occurring, the last entry in the journal prior to confirmation should be identified. In FIG. 5, this information is represented by confirmation boundary 600. For example, if the confirmation cycle identified in entry 569 begins just after entry 565 is written to the journal 502, confirmation boundary 600 would contain data identifying generation 605. In the illustrative embodiment shown in FIG. 5, confirmation boundary 600 may be written in the journal 502. In alternative embodiments, confirmation boundary 600 may be maintained elsewhere on data storage system 100.
A confirmation cycle may be performed by a confirmation manager or other module executed by data storage system 100. In one embodiment, the cycle may be performed by management modules 102 or 202 shown in FIG. 1. The confirmation cycle may begin by reviewing the journal 502. If the generation of the last entry in the journal 502 is greater than the confirmation boundary 600, unconfirmed entries exist in journal 502. In the exemplary embodiment depicted in FIG. 5, for example, the confirmation boundary 600 contains generation 605, which is the last confirmed generation in journal 502. The confirmation cycle would then attempt to confirm each entry in the journal 502 having a generation greater than generation 605. For each entry to be confirmed, the confirmation manager verifies the status associated with the asset identified in the entry, and if the status is �valid,� �failed,� or �destroyed,� confirmation can proceed. For example, when attempting to confirm entry 566, the confirmation manager checks status 425 of asset 401, which is identified in entry 566 by asset identifier 439. If the status is �valid,� confirmation proceeds for entry 566, which seeks to add to the reference count of asset part 407 (identified in entry 566 by unique identifier 432). In some embodiments, this verification may be done in a batch process, where the confirmation manager verifies the status associated with all assets associated with unconfirmed entries in the journal.
For example, entry 561 at generation 601 corresponds to an intention to add a reference to an asset part 403, which is indicated in FIG. 5 as �AR.� The entry further comprises the identifier 438 of the asset 400 having a forward reference to the asset part 403, and the unique identifier 410 of the asset part 403. If the exemplary asset 400 of FIG. 3 were ingested (i.e. a request to store asset 400 is received by the data storage system 100), at least two �AR� entries in the journal 502 may be created, for example, entry 561 and entry 562. Entry 561 would record the storage of asset part 403 and its association with asset 400, and entry 562 would record the storage of asset part 404 and its association with asset 400. Thus, when the intentions represented in entry 561 and entry 562 are completed, and asset 400 is ingested, the confirmed back reference counts 413, 419 of asset parts 403, 404 would be increased. In another embodiment, the metadata for asset parts 403 and 404 may be in different stripes within data storage system 100. For example, the metadata for asset part 403 may be in stripe 13 and the metadata for asset part 404 may be on stripe 14. In this case, the aforementioned entries would be made in the appropriate journal (i.e. entry 561 would be created in the journal associated with stripe 13 and entry 562 would be created in the journal associated with stripe 14).
For example, entry 567 at generation 607 corresponds to an intention to remove a reference to an asset part 403, which is indicated in FIG. 5 as �RR.� The entry further identifies the unique identifier of the asset having a forward reference to the asset part, and the identifier of the asset part. If the exemplary asset 400 of FIG. 3 were to be deleted (i.e. a request to remove asset 400 is received by the data storage system), at least two �RR� entries in the journal may be created, for example, entry 567 and entry 568. Entry 567 would comprise the asset identifier 438 of asset 400, and the unique asset part identifier 410 of asset part 403. Entry 568 would comprise the asset identifier 438 of asset 400, and the unique asset part identifier 416 of asset part 404. Thus, when the intentions represented in entry 567 and entry 568 are completed, the back reference counts 413, 419 of asset parts 403, 404 would be decreased since the asset 400 has been removed from the data storage system.
In stage 702, a first generation number is assigned to the first entry to the journal. This generation number may then be used during a confirmation cycle, shown in stage 703. FIG. 7 details stage 703. Stage 703 may begin with stage 704, in which the first generation number, which was assigned to the first entry, is compared to a second generation number that is associated with the asset part itself. The second generation number may be stored with the asset part or separately in a record associated with the asset part, such as in metadata record 30 of FIG. 4. This second generation number, represented, for example, in FIG. 4 as �confirmed generation 550,� represents the generation of the last journal entry that was confirmed relating to that asset part and is initialized to zero when the asset part is first created. In one embodiment, when the confirmation cycle is completed, the second generation number associated with the asset part is replaced with the first generation number corresponding to the most recent journal entry that has been confirmed for the asset part. In another embodiment, a generation number corresponding to the last confirmed entry in the journal (which may or may not be associated with the asset part) replaces the second generation number. In this way, the confirmed generation associated with the asset represents that last entry in the journal that has been confirmed. In one illustrative embodiment, the second generation associated with the asset part and the reference count are updated atomically.
Further, in some embodiments, the confirmation cycle does not cause the reference count associated with the asset part to change because in some instances, the asset referencing that asset part has a status that makes it ineligible to be changed. For example, if the asset status is �pending,� the reference count of the asset part should not be changed.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5287499May 16, 1991Feb 15, 1994Bell Communications Research, Inc.Methods and apparatus for information storage and retrieval utilizing a method of hashing and different collision avoidance schemes depending upon clustering in the hash tableUS5440727Jul 15, 1994Aug 8, 1995International Business Machines CorporationAsynchronous replica management in shared nothing architecturesUS5812398 *Jun 10, 1996Sep 22, 1998Sun Microsystems, Inc.Method and system for escrowed backup of hotelled world wide web sitesUS5813008Jul 12, 1996Sep 22, 1998Microsoft CorporationSingle instance storage of informationUS6041423Nov 8, 1996Mar 21, 2000Oracle CorporationMethod and apparatus for using undo/redo logging to perform asynchronous updates of parity and data pages in a redundant array data storage environmentUS6477544Jul 16, 1999Nov 5, 2002Microsoft CorporationSingle instance store for file systemsUS6629198Dec 8, 2000Sep 30, 2003Sun Microsystems, Inc.Data storage system and method employing a write-ahead hash logUS6678809Apr 13, 2001Jan 13, 2004Lsi Logic CorporationWrite-ahead log in directory management for concurrent I/O access for block storageUS6865577Nov 6, 2000Mar 8, 2005At&T Corp.Method and system for efficiently retrieving information from a databaseUS7003551 *Nov 30, 2000Feb 21, 2006Bellsouth Intellectual Property Corp.Method and apparatus for minimizing storage of common attachment files in an e-mail communications serverUS7093137Sep 26, 2000Aug 15, 2006Casio Computer Co., Ltd.Database management apparatus and encrypting/decrypting systemUS7165082 *Oct 31, 2003Jan 16, 2007Veritas Operating CorporationIncremental method for backup of email messagesUS7197599Dec 29, 2003Mar 27, 2007Intel CorporationMethod, system, and program for managing data updatesUS7254596Feb 19, 2004Aug 7, 2007Datacentertechnologies N.V.Efficient computer file backup system and methodUS7379549Jul 29, 2004May 27, 2008Sony United Kingdom LimitedAccess control for digital contentUS7424637Mar 21, 2003Sep 9, 2008Networks Appliance, Inc.Technique for managing addition of disks to a volume of a storage systemUS7433898 *Apr 26, 2005Oct 7, 2008Sanbolic, Inc.Methods and apparatus for shared storage journalingUS7457800 *Oct 6, 2005Nov 25, 2008Burnside Acquisition, LlcStorage system for randomly named blocks of dataUS7457813 *Oct 6, 2005Nov 25, 2008Burnside Acquisition, LlcStorage system for randomly named blocks of dataUS7469260 *Aug 28, 2003Dec 23, 2008Hitachi, Ltd.File storage service system, file management device, file management method, ID denotative NAS server and file reading methodUS7653836 *Jun 9, 2006Jan 26, 2010American Megatrends, IncLogging metadata modifications in a data storage systemUS7672981 *Feb 28, 2007Mar 2, 2010Emc CorporationObject classification and indexing of very large name spaces using grid technologyUS7716060Feb 23, 2001May 11, 2010Germeraad Paul BPatent-related tools and methodology for use in the merger and acquisition processUS7818517 *Sep 29, 2006Oct 19, 2010Emc CorporationArchitecture for virtualization of networked storage resourcesUS7827150 *Apr 30, 2007Nov 2, 2010Symantec CorporationApplication aware storage appliance archivingUS7849059 *Nov 28, 2006Dec 7, 2010Commvault Systems, Inc.Data classification systems and methods for organizing a metabaseUS20030028783Jul 19, 2002Feb 6, 2003Mark CollinsSecurity systemUS20030120864 *Dec 9, 2002Jun 26, 2003Lee Edward K.High-performance log-structured RAIDUS20030145167 *Jan 29, 2003Jul 31, 2003Kabushiki Kaisha ToshibaDisk array apparatus for and method of expanding storage capacity dynamicallyUS20030188153Apr 2, 2002Oct 2, 2003Demoff Jeff S.System and method for mirroring data using a serverUS20040024739Jul 1, 2003Feb 5, 2004Kanisa Inc.System and method for implementing a knowledge management systemUS20040049700Mar 6, 2003Mar 11, 2004Fuji Xerox Co., Ltd.Distributive storage controller and methodUS20040111557 *Feb 14, 2003Jun 10, 2004Yoji NakataniUpdated data write method using journal logUS20050015416Jul 16, 2003Jan 20, 2005Hitachi, Ltd.Method and apparatus for data recovery using storage based journalingUS20050033777 *Aug 4, 2003Feb 10, 2005Moraes Mark A.Tracking, recording and organizing changes to data in computer systemsUS20050114399Nov 10, 2004May 26, 2005Pioneer CorporationData classification method, summary data generating method, data classification apparatus, summary data generating apparatus, and information recording mediumUS20050262361May 24, 2004Nov 24, 2005Seagate Technology LlcSystem and method for magnetic storage disposalUS20060031230 *Jul 20, 2005Feb 9, 2006Kumar Sinha MData storage systemsUS20060106811Nov 17, 2005May 18, 2006Steven BlumenauSystems and methods for providing categorization based authorization of digital assetsUS20060106884Nov 17, 2005May 18, 2006Steven BlumenauSystems and methods for storing meta-data separate from a digital assetUS20060106898Nov 17, 2004May 18, 2006Frondozo Rhea RMethod, system, and program for storing and using metadata in multiple storage locationsUS20060112112 *Oct 6, 2005May 25, 2006Margolus Norman HStorage system for randomly named blocks of dataUS20060136735Feb 7, 2006Jun 22, 2006Serge PlotkinEncryption based security system for network storageUS20060143168Dec 29, 2004Jun 29, 2006Rossmann Albert PHash mapping with secondary table having linear probingUS20060206662Jul 1, 2005Sep 14, 2006Ludwig Thomas ETopology independent storage arrays and methodsUS20060224846 *Nov 7, 2005Oct 5, 2006Amarendran Arun PSystem and method to support single instance storage operationsUS20060230244 *Nov 8, 2005Oct 12, 2006Amarendran Arun PSystem and method for performing auxillary storage operationsUS20060235908Apr 15, 2005Oct 19, 2006Emc CorporationMethods and apparatus for managing the replication of contentUS20060236029 *Apr 15, 2005Oct 19, 2006Corrado Francis RPower-safe disk storage apparatus, systems, and methodsUS20060248055Apr 28, 2005Nov 2, 2006Microsoft CorporationAnalysis and comparison of portfolios by classificationUS20060248273Apr 29, 2005Nov 2, 2006Network Appliance, Inc.Data allocation within a storage system architectureUS20060265370May 17, 2005Nov 23, 2006Cisco Technology, Inc. (A California Corporation)Method and apparatus for reducing overflow of hash table entriesUS20060271547 *May 25, 2005Nov 30, 2006Microsoft CorporationCluster storage collection based data managementUS20060288161 *Jun 17, 2005Dec 21, 2006Cavallo Joseph SRAID power safe apparatus, systems, and methodsUS20070110044Oct 31, 2006May 17, 2007Matthew BarnesSystems and Methods for Filtering File System Input and OutputUS20070112883Jan 11, 2006May 17, 2007Hitachi, Ltd.Computer system, managing computer and recovery management methodUS20070180000 *Mar 13, 2006Aug 2, 2007Hiroshi MineStorage apparatus and storage systemUS20080005194Apr 20, 2007Jan 3, 2008Lockheed Martin CorporationSystem and method for immutably cataloging and storing electronic assets in a large scale computer systemUS20080243878 *Mar 29, 2007Oct 2, 2008Symantec CorporationRemovalUS20080243953 *Mar 30, 2007Oct 2, 2008Weibao WuImplementing read/write, multi-versioned file system on top of backup dataUS20080263363Jan 22, 2008Oct 23, 2008Spyrus, Inc.Portable Data Encryption Device with Configurable Security Functionality and Method for File EncryptionUS20090259669Apr 10, 2008Oct 15, 2009Iron Mountain IncorporatedMethod and system for analyzing test data for a computer applicationUS20100082672 *Sep 23, 2009Apr 1, 2010Rajiv KottomtharayilSystems and methods for managing single instancing dataUS20100088280 *Jan 16, 2009Apr 8, 2010Hitachi, Ltd.Computer system for hierarchically managing a journal and method thereforUS20100153338 *Feb 25, 2010Jun 17, 2010David NgoSystems and Methods for Resynchronizing InformationUS20100215175Mar 11, 2009Aug 26, 2010Iron Mountain IncorporatedMethods and systems for stripe blind encryptionUS20100217931Mar 11, 2009Aug 26, 2010Iron Mountain IncorporatedManaging workflow communication in a distributed storage systemUS20100217953Jun 15, 2009Aug 26, 2010Beaman Peter DHybrid hash tablesEP1818847A2Feb 8, 2007Aug 15, 2007Ricoh Company, Ltd.Data encoding apparatus, data encoding method, data encoding program, and recording medium* Cited by examinerNon-Patent CitationsReference1Advisory Action dated Mar. 2, 2011, issued in U.S. Appl. No. 12/100,962, by Abbruzzi et al., filed Apr. 10, 2008.2Broder, A. et al. "Using Multiple Hash Functions to Improve IP Lookups" IEEE INFOCOM 2001: 20th Annual Joint Conference of the IEEE Computer and Communications Society, Anchorage, Alaska, Apr. 22-26, 2001; Proceedings, vol. 3, pp. 1454-1463.3Decandia, Giuseppe et al., Dynamo: Amazon's Highly Available Key-value Store, Amazon.com, SOSP'07, Oct. 14-17, 2007, Stevenson, Washington, pp. 205-220.4Final Office Action dated Dec. 23, 2010, issued in U.S. Appl. No. 12/100,962, by Abbruzzi et al., filed Apr. 10, 2008.5Guy, Richard G., Ficus: A Very Large Scale Reliable Distributed File System, Technical Report CSD-910018, Computer Science Department, University of California, Los Angeles, CA, Jun. 3, 1991.6Honicky, R.J. et al., Replication Under Scalable Hashing: A Family of Algorithms for Scalable Decentralized Data Distribution, Proceedings of the 18th International Parallel and Distributed Processing Symposium, Santa Fe, NM, Apr. 2004.7International Business Machines Corp. (IBM) "Cache Hash Overflow Table for Computers Using Cache Memory" Technical Disclosure Bulletin, vol. 32, No. 3B, pp. 110-117 (Aug. 1, 1989).8International Search Report and Written Opinion issued in International Patent Application No. PCT/US2010/024784; Date of Mailing: Jul. 13, 2010.9International Search Report and Written Opinion issued in International Patent Application No. PCT/US2010/024787; Date of Mailing: May 18, 2010.10International Search Report and Written Opinion issued in International Patent Application No. PCT/US2010/024889; Date of Mailing: Oct. 22, 2010.11International Search Report and Written Opinion issued in International Patent Application No. PCT/US2010/024891; Date of Mailing: Sep. 22, 2010.12Jenkins, Bob, "Hash Functions", Dr. Dobb's Journal, Sep. 1, 1997, available at http//www.ddj.com/architect/184410284 (5 pages).13Jenkins, Robert J., "Hash Functions for Hash Table Lookup", 1995-1997, http//www.burtleburtle.net/bob/hash/evahash.html (8 pages).14Kirsch, A. et al. "On the Performance of Multiple Choice Hash Tables with Moves on Deletes and Inserts" 2008 46th Annual Allerton Conference on Communication, Control, and Computing. Allerton House, UIUC, Illinois, USA, Sep. 23-26, 2008 IEEE; ThD1.4, pp. 1284-1290.15Kumar, S. et al. "Segmented Hash: An Efficient Hash Table Implementation for High Performance Networking Subsystems" Proceedings of the Symposium on Architecture for Networking and Communications Systems (ANCS), Oct. 26-28, 2005, Princeton, New Jersey; pp. 91-103.16Microsoft IT Showcase, Single Instance Storage in Microsoft Windows Storage Server 2003 R2: A Solution for Managing Duplicate Files, Technical White Paper, May 2006.17Mohan, C. et al., ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging, Association for Computing Machinery, ACM Transactions on Database Systems, vol. 17, No. 1, Mar. 1992, pp. 94-162.18Partial International Search Report, Annex to Invitation to Pay Fees, issued in International Patent Application No. PCT/US2010/024891; Date of Mailing: Jun. 24, 2010.19Satyanarayanan, M., Coda: A Highly Available File System for a Distributed Workstation Environment, IEEE Transactions on Computers, vol. 39, p. 447-459 (1990), available at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.1314.20Seagate "The Benefits of Self-Encrypting Drives in the Data Center" Technology Paper, Publication No. TP590.1-0804US, Apr. 1, 2008 [online]. Retrieved from the Internet: http://www.lsi.com/campaigns/forms/security-cw/downloads/pdf/TP590.1-0804US-lr.pdf.21Seagate "The Benefits of Self-Encrypting Drives in the Data Center" Technology Paper, Publication No. TP590.1-0804US, Apr. 1, 2008 [online]. Retrieved from the Internet: http://www.lsi.com/campaigns/forms/security�cw/downloads/pdf/TP590.1-0804US�lr.pdf.22Weil, Sage A. et al., Ceph: A Scalable, High-Performance Distributed File System, OSDI '06: 7th USENIX Symposium on Operating Systems Design and Implementation, pp. 307-320.23Weil, Sage A. et al., CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data, IEEE, SC2006, Nov. 2006, Tampa, Florida.24Wikipedia "Key derivation function" Dec. 25, 2008 [online]. Retrieved from the Internet: http://en.wikipedia.org/w/index.php?title=Key-derivation-function&oldid=260028157.25Wikipedia "Key derivation function" Dec. 25, 2008 [online]. Retrieved from the Internet: http://en.wikipedia.org/w/index.php?title=Key�derivation�function&oldid=260028157.26Wikipedia, List of file systems, Nov. 27, 2007, http//en.wikipedia.org/wiki/List-of-file-systems.27Wikipedia, List of file systems, Nov. 27, 2007, http//en.wikipedia.org/wiki/List�of�file�systems.28Wikipedia, Replication (Computer Science), Nov. 27, 2007, http://en.wikipedia.org/wiki/Replication-%28computer-science%29.29Wikipedia, Replication (Computer Science), Nov. 27, 2007, http://en.wikipedia.org/wiki/Replication�%28computer�science%29.30Xin, Qin et al., Evaluation of Distributed Recovery in Large-Scale Storage Systems, Proceedings of the 13th IEEE International Symposium on High Performance Distributed Computing, Honolulu, HI, Jun. 2004.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8806175Feb 6, 2013Aug 12, 2014Longsand LimitedHybrid hash tablesClassifications U.S. Classification707/610, 707/648, 707/634, 707/633, 707/812, 707/635, 707/615, 707/640International ClassificationG06F17/00Cooperative ClassificationG06F17/30191, G06F11/2094, G06F11/1662European ClassificationG06F17/30F, G06F11/16D2Legal EventsDateCodeEventDescriptionApr 25, 2012ASAssignmentFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IRON MOUNTAIN INCORPORATED;REEL/FRAME:028103/0838Effective date: 20110531Owner name: AUTONOMY, INC., CALIFORNIAApr 17, 2009ASAssignmentFree format text: CORRECTIVE ASSIGNMENT TO CORRECT THE FILING DATE PREVIOUSLY RECORDED ON REEL 022303 FRAME 0967. ASSIGNOR(S) HEREBY CONFIRMS THE FILING DATE SHOULD READ 02/23/2009;ASSIGNORS:BEAMAN, PETER D.;TRAN, TUYEN M.;NEWSON, ROBERT S.;SIGNING DATES FROM 20090222 TO 20090223;REEL/FRAME:022563/0862Owner name: IRON MOUNTAIN INCORPORATED, MASSACHUSETTSFeb 24, 2009ASAssignmentFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BEAMAN, PETER D.;TRAN, TUYEN M.;NEWSON, ROBERT S.;SIGNING DATES FROM 20090222 TO 20090223;REEL/FRAME:022303/0967Owner name: IRON MOUNTAIN INCORPORATED, MASSACHUSETTSRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services