Source: http://www.google.com/patents/US7702869?dq=6,757,682
Timestamp: 2015-04-19 18:28:44
Document Index: 545940438

Matched Legal Cases: ['art 702', 'art 704', 'art 706', 'art 702', 'art 702', 'art 704', 'art 1', 'art 1', 'art 704', 'art 1', 'art 1', 'art 704', 'art 1', 'art 704', 'art 702', 'art 704']

Patent US7702869 - System and method for verifying the consistency of mirrored data sets - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA system and method for verifying the consistency of mirrored data sets is provided. A verification module executed on a destination storage system transmits a list of desired persistent consistency point images (PCPIs) to a source destination storage system. The source destination storage system identifies...http://www.google.com/patents/US7702869?utm_source=gb-gplus-sharePatent US7702869 - System and method for verifying the consistency of mirrored data setsAdvanced Patent SearchPublication numberUS7702869 B1Publication typeGrantApplication numberUS 12/330,013Publication dateApr 20, 2010Filing dateDec 8, 2008Priority dateApr 28, 2006Fee statusPaidAlso published asUS7464238Publication number12330013, 330013, US 7702869 B1, US 7702869B1, US-B1-7702869, US7702869 B1, US7702869B1InventorsVikas YadavOriginal AssigneeNetapp, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (62), Non-Patent Citations (49), Classifications (11), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetSystem and method for verifying the consistency of mirrored data sets
A known type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block is retrieved (read) from disk into a memory of the storage system and �dirtied� (i.e., updated or modified) with new data, the data block is thereafter stored (written) to a new location on disk to optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An is example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL�) file system available from Network Appliance, Inc., Sunnyvale, Calif.
In order to improve reliability and facilitate disaster recovery in the event of a failure of a storage system, its associated disks or some portion of the storage infrastructure, it is common to �minor� or replicate a data set comprising of some or all of the underlying data and/or the file system that organizes the data. A data set comprises an area of defined storage which may have a mirroring relationship associated therewith. Examples of data sets include, e.g., a file system, a volume or a persistent consistency point image (PCPI), described further below.
One common form of update involves the use of a �snapshot� process in which the active file system at the source storage site, consisting of inodes and blocks, is captured and the changes between two snapshots are transmitted, over a network (such as the well-known Internet) to the remote destination storage site. Such mirroring techniques are described in the above-incorporated U.S. Patent Applications. By �active file system� it is meant the file system to which current input/output operations are being directed.
Note that the term �snapshot� is a trademark of Network Appliance, Inc. It is used for purposes of this patent to designate a persistent consistency point image (PCPI). A persistent consistency point image is a point in time representation of the storage system, and more particularly, of the active file system, stored on a storage device or in other persistent memory and having a name or other unique identifier that distinguishes it from other PCPIs taken at other points in time. A PCPI can also include other information (metadata) about the active file system at the particular point in time for which the image is taken. The terms PCPI and snapshot may be used interchangeably through out this patent without derogation of Network Appliance's is trademark rights. The PCPI process is described in further detail in U.S. patent application Ser. No. 09/932,578, now issued as U.S. Pat. No. 7,454,445 on Nov. 18, 2008, entitled INSTANT SNAPSHOT by Blake Lewis et al., TR3002 File System Design for an NFS File Server Appliance by David Hitz et al., published by Network Appliance, Inc., and in U.S. Pat. No. 5,819,292 entitled METHOD FOR MAINTAINING CONSISTENT STATES OF A FILE SYSTEM AND FOR CREATING USERACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM by David Hitz et al., which are hereby incorporated by reference.
An exemplary PCPI-based mirroring technique typically provides for remote asynchronous replication or mirroring of changes made to a source file system PCPI in a destination replica file system. The mirroring technique typically scans (via a scanner) the blocks that make up two versions of a PCPI of the source file system, to identify latent divergence, i.e., changed blocks in the respective PCPI files based upon differences in vbns further identified in a scan of a logical file block index of each PCPI. Trees (e.g., buffer trees) of blocks associated with the files are traversed, bypassing unchanged pointers between versions, to identify the changes in the hierarchy of the trees. These changes are transmitted to the destination replica or �mirror.� This technique allows regular files, directories, inodes and any other hierarchical structure of trees to be efficiently scanned to determine differences (latent divergence) between versions thereof. A set number of PCPIs may be retained both on the source and the destination depending upon various time-based and other criteria.
The verification daemon compares the list of PCPIs with a list of local PCPIs, i.e., those PCPIs that are stored on the source, to find a common subset and then returns a list of common PCPIs to the verification module. The verification daemon also locks the set of common PCPIs for the duration of the verification procedure. Upon receiving the list of common PCPIs, the verification module locks the corresponding common PCPIs and initiates a verification process for each of them. Each verification process establishes a connection with the verification demon, which initializes a new thread (a �verification thread�) for each connection. Each verification thread then transmits a stream of verification data to the appropriate destination verification process utilizing a file system independent protocol format. In an illustrative embodiment, the verification data may comprise metadata associated with the PCPI while, in alternate embodiments, the verification data may comprise checksums or the full data of the PCPI. The verification data is transmitted to the destination storage system and compared with corresponding data on the local file system by the verification module.
FIG. 1 is a schematic block diagram of a storage system environment 100 that includes a pair of interconnected storage systems including a source storage system 110 and a destination storage system 112 that may be advantageously used with the present invention. For the purposes of this description, the source storage system is a networked computer that manages storage on one or more source volumes 114, each comprising an array of storage disks 160 (described further below). Likewise, the destination storage system 112 manages the storage on one or more destination volumes 116 comprising arrays of disks 160. The source and destination storage systems are linked via a network 118 that can comprise a local or wide area network, such as the well-known Internet. An appropriate network adapter 130 residing in each storage system 110, 112 facilitates communication over the network 118. Also for the purposes of this description, like components in each of the source and destination storage system 110 and 112 respectively, are described with like reference numerals. As used herein, the term �source� can be broadly defined as a location from which the subject data travels during a mirroring operation and the term �destination� can be defined as the location to which the data travels. While a source storage system and a destination storage system, connected by a network, is a particular example of a source and destination used herein, a source and destination could be computers/storage systems linked via a direct link, or via loopback (a �networking� arrangement internal to a single computer for transmitting a data stream between local source and local destination), in which case the source and the destination are the same storage system.
It will be understood to those skilled in the art that the inventive technique described herein may apply to any type of special-purpose computer (e.g., file serving appliance) or general-purpose computer, including a standalone computer, embodied as a storage system. The storage system may be further implemented as a storage appliance. An example of a multi-protocol storage appliance that may be advantageously used with the present invention is described in U.S. patent application Ser. No. 10/215,917 titled, MULTI-PROTOCOL STORAGE APPLIANCE THAT PROVIDES INTEGRATED SUPPORT FOR FILE AND BLOCK ACCESS PROTOCOLS, filed on Aug. 8, 2002 and published on Feb. 12, 2004 as U.S. Patent Publication No. 2004/0030668. Moreover, the teachings of this invention can be adapted to a variety of storage system architectures including, but not limited to, a network-attached storage environment, a storage area network and disk assembly directly-attached to a client or host computer. The term �storage system� should therefore be taken broadly to include such arrangements in addition to any subsystems configured to perform a storage function and associated with other equipment or systems.
In the illustrative embodiment, the memory 125 comprises storage locations that are addressable by the processor and adapters for storing software program code. The memory comprises a form of random access memory (RAM) that is generally cleared by a power cycle or other reboot operation (i.e., it is �volatile� memory). The processor and adapters may, in turn, comprise processing elements and/or logic circuitry configured to execute the software code and manipulate the data structures. The operating system 200, portions of which are typically resident in memory and executed by the processing elements, functionally organizes the storage system by, inter alia, invoking storage operations in support of a file service implemented by the storage system. It will be apparent to those skilled in the art that other processing and memory means, including various computer readable media, may be used for storing and executing program instructions pertaining to the inventive technique described herein.
To facilitate access to the disks 160, the storage operating system 200 illustratively implements a write-anywhere file system that cooperates with virtualization modules to �virtualize� the storage space provided by disks 160. The file system logically organizes the information as a hierarchical structure of named directories and files on the disks. Each �on-disk� file may be implemented as set of disk blocks configured to store information, such as data, whereas the directory may be implemented as a specially formatted file in which names and links to other files and directories are stored. The virtualization modules allow the file system to further logically organize information as a hierarchical structure of blocks on the disks that are exported as named logical unit numbers (luns).
Operationally, a request from the client is forwarded as a packet 155 over the computer network 118 and onto the storage system where it is received at the network adapter. A network driver (of layer 205 or layer 240) processes the packet and, if appropriate, passes it on to a network protocol and file access layer for additional processing prior to forwarding to the write-anywhere file system 285. Here, the file system generates operations to load (retrieve) the requested data from disk if it is not resident �in core�, i.e., in memory 125. If the information is not in the memory, the file system indexes into the inode file using the inode number to access an appropriate entry and retrieve a logical vbn. The file system then passes a message structure including the logical vbn to the RAID system 260; the logical vbn is mapped to a disk identifier and disk block number (disk,dbn) and sent to an appropriate driver (e.g., SCSI) of the disk driver system 265. The disk driver accesses the dbn from the specified disk and loads the requested data block(s) in memory 125 for processing by the storage system. Upon completion of the request, the storage system (and operating system) returns a reply to the client over the network 118.
As noted above, in certain mirroring architectures, storage systems utilize PCPIs. For example, source storage system 110 (�source�) may generate a baseline PCPI that is transferred to destination storage system 112 (�destination�). At a later point in time, the source storage system may generate a second PCPI. The mirroring application module 295 determines the changes between the baseline and the second PCPIs, with only those changes being transmitted to the destination, which may then update its file system and generate a second PCPI so that the baseline and second PCPIs are identical on both the source and destination.
An exemplary file system inode structure 300 according to an illustrative embodiment is shown in FIG. 3. The inode for the inode file or more generally, the �root� inode 305 contains information describing inode file 308 associated with a given file system. In this exemplary file system inode structure root inode 305 contains a pointer to is the inode file indirect block 310. The inode file indirect block 310 points to one or more inode file direct blocks 312, each containing a set of pointers to inodes 315 that make up the inode file 308. The depicted subject inode file 308 is organized into volume blocks (not separately shown) made up of inodes 315 which, in turn, contain pointers to file data (or �disk�) blocks 320A, 320B and 320C. In the diagram, this is simplified to show just the inode itself containing pointers to the file data blocks. Each of the file data blocks 320(A-C) is adapted to store, in the illustrative embodiment, 4 kilobytes (KB) of data. Note, however, where more than a predetermined number of file data blocks are referenced by an inode (315), one or more indirect blocks 325 (shown in phantom) are used. These indirect blocks point to associated file data blocks (not shown).
The verification daemon compares the list of PCPIs with a list of local PCPIs, i.e., those PCPIs that are stored on the source, to find a common subset and then returns a list of common PCPIs to the verification module. Upon receiving the list of common PCPIs, the verification module locks the corresponding common PCPIs and initiates a verification process for each of them. Each verification process establishes a connection with the verification demon, which initializes a new thread (a �source thread�) for each connection. Each source thread then transmits a stream of verification data desired by the destination to the appropriate destination verification process. In an illustrative embodiment, the verification data may comprise metadata associated with the PCPI, which in alternate embodiments, the verification data checksums or may comprise the complete data of the PCPI. The verification data is transmitted to the destination storage system and compared with corresponding data on the local file system by the verification module.
In response, the verification module, in step 615, sends a connection request to the verification daemon executing on the source storage system. The verification daemon executing on the source storage system receives the connection request and, in step 620, launches a new thread (a �verification thread�) to process the received connection request. Then, in step 625, the verification thread, returns an acknowledgment to the verification module. In response to receiving the acknowledgment, the verification module, in step 630, sends a list of PCPIs that the administrator desires to verify to the verification thread. As noted above, this list of PCPIs illustratively may be identified using the -d option to the verification module.
Illustratively, a file system-independent format is used to transmit a data stream of changed data over the network. This format consists of a set of standalone headers with unique identifiers. Some headers refer to follow-on data and others carry relevant data within the stream. For example, the information relating to any source PCPI deleted files are carried within �deleted files� headers. All directory activity is transmitted first, followed by file data. File data is sent in chunks of varying size, separated by regular headers until an ending header (footer) is provided. At the destination, the format is unpacked and inodes contained therein are transmitted over the network and mapped to a new directory structure. Received file data blocks are written according to their offset in the corresponding destination file. An inode map stores entries which map the source's inodes (files) to the destination's inodes (files). The inode map also contains generation numbers. The tuple of (inode number, generation number) allows the system to create a file handle for fast access to a file. It also allows the system to track changes in which a file is deleted and its inode number is reassigned to a newly created file.
To facilitate construction of a new directory tree on the destination, an initial directory stage of the destination minor process receives source directory information via the format and moves any deleted or moved files to a temporary or �purgatory� directory. The purgatory files which have been moved are �hard linked,� i.e., appropriate directory entries are created in the directories to which they have been moved. Newly created source files are entered into the inode map and built into the directory tree. After the directory tree is built, the transfer of file data begins. Changes to file data from the source are written to the corresponding replica files (as identified by the inode map). When the data stream transfer is complete, the purgatory directory is removed and any unlinked files (including various deleted files) are permanently deleted. In one embodiment, a plurality of discrete source qtrees or other sub-directory derived from different source volumes can be replicated/mirrored on a single destination volume.
The data stream is described further below. In general, its use is predicated upon having a structure that supports multiple protocol attributes (e.g. Unix permissions, NT access control lists (ACLs), multiple file names, NT streams, file type, file-create/modify time, etc.). The format also identifies the data in the stream (i.e. the offset location in a file of specific data or whether files have �holes� in the file offset that should remain free). The names of files are also relayed by the format. More generally, the format is independent of the underlying network protocol or device (in the case of a tape or local disk/non-volatile storage) protocol and file system�that is, the information is system �agnostic,� and not bound to a particular operating system software, thereby allowing source and destination systems of different vendors to share the information. The format is, thus, completely self-describing requiring no information outside the data stream. In this manner a source file directory of a first type can be readily translated into destination file directory of a different type. The format also allows extensibility, in that newer improvements to the source or destination operating system does not affect the compatibility of older versions. In particular, a data set (e.g. a new header) that is not recognized by the operating system is ignored or dealt with in a predictable manner without triggering a system crash or other unwanted system failure (i.e. the stream is backwards compatible). This format also enables transmission of a description of the whole file system, or a description of only changed blocks/information within any file or directory. In addition, the format generally minimizes network and processor overhead.
The format into which source PCPI changes are organized is shown schematically in FIGS. 7 and 8. The format is illustratively organized around 4 KB blocks. The header size and arrangement can widely vary in alternate embodiments, however. There are 4 KB headers that are identified by certain �header types.� Basic data stream headers (�data�) are provided for at most every 2 megabytes (2 MB) of changed data. With reference to FIG. 7, the 4 KB standalone header includes three parts, a 1 KB generic part 702, a 2 KB non-generic part 704, and a 1 KB expansion part 706. The expansion part is not used, but is available for later versions.
The generic part 702 contains an identifier of header type 710. Standalone header types (i.e. headers not followed by associated data) can indicate a start of the data stream; an end of part one of the data stream; an end of the data stream; a list of deleted files encapsulated in the header; or the relationship of any NT stream directories. Later versions of Windows NT allow for multiple NT �streams� related to particular filenames. A discussion of streams is found in U.S. Pat. No. 6,643,654 B1, entitled SYSTEM AND METHOD FOR REPRESENTING NAMED DATA STREAMS WITHIN AN ON-DISK STRUCTURE OF A FILE SYSTEM, by Kayuri Patel, et al, the teachings of which are expressly incorporated herein by reference. Also in the generic part 702 is a checksum 712 that ensures the header is not corrupted. In addition other data such as a �checkpoint� 714 used by the source and destination to track the progress of replication is provided. By providing a list of header types, the destination can more easily operate in a backwards-compatible mode�that is, a header type that is not recognized by the destination (provided from a newer version of the source) can be more easily ignored, while recognized headers within the limits of the destination version are processed as usual.
FIG. 8 describes the format of the illustrative replication data stream in further detail. The format of the replicated data stream is headed by a standalone data stream header 802 of the type �start of data stream.� This header contains data in the non-generic part 704 generated by the source describing the attributes of the data stream.
Next a series of headers and follow-on data in the format 1020 define various �part 1� information 804. Significantly, each directory data set transmitted is preceded by a basic header with no non-generic data. Only directories that have been modified are transmitted, and they need not arrive in a particular order. Note also that the data from any particular directory need not be contiguous. Each directory entry is loaded into a 4 KB block. Any overflow is loaded into a new 4 KB block. Each directory entry is a header followed by one or more names. The entry describes an inode and the directory names to follow. NT stream directories are also transmitted.
The part 1 format information 804 also provides access control list ACL information for every file that has an associated ACL. By transmitting the ACLs before their associated file data, the destination can set ACLs before file data is written. ACLs are transmitted in a �regular� file format. Deleted file information (described above) is sent with such information included in the non-generic part 704 of one or more standalone headers (if any). By sending this information in advance, a directory tree builder can differentiate between moves and deletes.
Once various part 1 information 804 is transmitted, the format calls for an �end of part 1 of the data stream� header 806. This is a basic header having no data in the non-generic part 704. This header tells the destination that part 1 is complete and to now expect file data.
In addition, referring to the header in FIG. 7, the basic header includes a block numbers data structure 730, associated with the non-generic part 704 works in conjunction with the �holes array� 732 within (in this example) the generic part 702. The holes array denotes empty space. This structure, in essence, provides the mapping from the holes array to corresponding blocks in the file. This structure instructs the destination where to write data blocks or holes.
In general files 812 are written in 4 KB chunks with basic headers at every 512 chunks (2 MB), at most. Likewise, streams (also 812) are transmitted like regular files in 4 KB chunks with at most 2 MB between headers. Finally, the end of the replicated data stream format is marked by a footer 820 consisting of standalone header of the type �end of data stream.� This header has no specific data in its non-generic part 704 (FIG. 7).
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4570217Mar 28, 1983Feb 11, 1986Allen Bruce SMan machine interfaceUS5163131Sep 8, 1989Nov 10, 1992Auspex Systems, Inc.Parallel i/o network file server architectureUS5202979Jun 26, 1992Apr 13, 1993Thinking Machines CorporationStorage system using multiple independently mechanically-driven storage unitsUS5278979Dec 20, 1990Jan 11, 1994International Business Machines Corp.Version management system using pointers shared by a plurality of versions for indicating active lines of a versionUS5355453Oct 13, 1992Oct 11, 1994Auspex Systems, Inc.For use with a data network and a mass storage deviceUS5403639Sep 2, 1992Apr 4, 1995Storage Technology CorporationFile server having snapshot application data groupsUS5410667Apr 17, 1992Apr 25, 1995Storage Technology CorporationData record copy system for a disk drive array data storage subsystemUS5485579Apr 8, 1994Jan 16, 1996Auspex Systems, Inc.Multiple facility operating system architectureUS5802366Oct 11, 1994Sep 1, 1998Auspex Systems, Inc.Parallel I/O network file server architectureUS5819292May 31, 1995Oct 6, 1998Network Appliance, Inc.Method for maintaining consistent states of a file system and for creating user-accessible read-only copies of a file systemUS5835953Nov 8, 1996Nov 10, 1998Vinca CorporationBackup system that takes a snapshot of the locations in a mass storage device that has been identified for updating prior to updatingUS5931918Jul 30, 1997Aug 3, 1999Auspex Systems, Inc.For use with a data network and a mass storage deviceUS5941972Dec 31, 1997Aug 24, 1999Crossroads Systems, Inc.Storage router and method for providing virtual local storageUS5963962Jun 30, 1998Oct 5, 1999Network Appliance, Inc.Method for generating a consistency pointUS5987506May 2, 1997Nov 16, 1999Mangosoft CorporationRemote access and geographically distributed computers in a globally addressable storage environmentUS6065037Jun 7, 1995May 16, 2000Auspex Systems, Inc.Multiple software-facility component operating system for co-operative processor control within a multiprocessor computer systemUS6240409Jul 31, 1998May 29, 2001The Regents Of The University Of CaliforniaMethod and apparatus for detecting and summarizing document similarity within large document setsUS6289356Sep 14, 1998Sep 11, 2001Network Appliance, Inc.Write anywhere file-system layoutUS6425035Sep 27, 2001Jul 23, 2002Crossroads Systems, Inc.Storage router and method for providing virtual local storageUS6466696May 17, 1999Oct 15, 2002Canon Kabushiki KaishaDeriving polygonal boundaries from quadtree representationUS6473767Apr 26, 2000Oct 29, 2002International Business Machines CorporationFile system for a computer and method of synchronizing sets of filesUS6493796Sep 1, 1999Dec 10, 2002Emc CorporationMethod and apparatus for maintaining consistency of data stored in a group of mirroring devicesUS6574591Oct 25, 1999Jun 3, 2003Network Appliance, Inc.File systems image transfer between dissimilar file systemsUS6604118Jul 31, 1998Aug 5, 2003Network Appliance, Inc.File system image transferUS6606694Dec 22, 2000Aug 12, 2003Bull Hn Information Systems Inc.Write logging in mirrored disk subsystemsUS6643654Jun 25, 2001Nov 4, 2003Network Appliance, Inc.System and method for representing named data streams within an on-disk structure of a file systemUS6662196Mar 16, 2001Dec 9, 2003Iti, Inc.Collision avoidance in bidirectional database replicationUS6668264Apr 3, 2001Dec 23, 2003Network Appliance, Inc.Resynchronization of a target volume with a source volumeUS6748504Feb 15, 2002Jun 8, 2004International Business Machines CorporationDeferred copy-on-write of a snapshotUS6889228Mar 29, 2001May 3, 2005Network Appliance, Inc.Cascading support for mirrored volumesUS6915316Dec 15, 2003Jul 5, 2005Network Appliance, Inc.One or more snapshots are used to compare data included in the source and target volume; instead of transferring the entire volume, only the data that is missing from a source and a target volume is transferredUS6993539Mar 19, 2002Jan 31, 2006Network Appliance, Inc.System and method for determining changes in two snapshots and for transmitting changes to destination snapshotUS7007046Mar 19, 2002Feb 28, 2006Network Appliance, Inc.Format for transmission file system information between a source and a destinationUS7010553Mar 19, 2002Mar 7, 2006Network Appliance, Inc.System and method for redirecting access to a remote mirrored snapshotUS7039663Apr 19, 2002May 2, 2006Network Appliance, Inc.System and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshotUS7043485Mar 19, 2002May 9, 2006Network Appliance, Inc.System and method for storage of snapshot metadata in a remote fileUS7203796Oct 24, 2003Apr 10, 2007Network Appliance, Inc.Method and apparatus for synchronous data mirroringUS7225204Mar 19, 2002May 29, 2007Network Appliance, Inc.System and method for asynchronous mirroring of snapshots at a destination using a purgatory directory and inode mappingUS7249150Jul 3, 2001Jul 24, 2007Network Appliance, Inc.System and method for parallelized replay of an NVRAM log in a storage applianceUS7464238Apr 28, 2006Dec 9, 2008Network Appliance, Inc.System and method for verifying the consistency of mirrored data setsUS7603391Jan 20, 2006Oct 13, 2009Netapp, Inc.System and method for determining changes in two snapshots and for transmitting changes to a destination snapshotUS20020049720May 11, 2001Apr 25, 2002Chase Manhattan BankSystem and method of data miningUS20020078041Oct 12, 2001Jun 20, 2002Wu William ChyiSystem and method of translating a universal query language to SQLUS20020083037Aug 17, 2001Jun 27, 2002Network Appliance, Inc.Instant snapshotUS20020178146May 24, 2001Nov 28, 2002International Business Machines CorporationSystem and method for selective object history retentionUS20030041211Mar 7, 2002Feb 27, 2003Merkey Jeffrey VernonDual axis RAID systems for enhanced bandwidth and reliabilityUS20030070043Mar 7, 2002Apr 10, 2003Jeffrey Vernon MerkeyHigh speed fault tolerant storage systemsUS20030158861Feb 15, 2002Aug 21, 2003International Business Machines CorporationProviding a snapshot of a subset of a file systemUS20030158863Feb 15, 2002Aug 21, 2003International Business Machines CorporationFile system snapshot with ditto address featureUS20030158873Feb 15, 2002Aug 21, 2003International Business Machines CorporationDynamic links to file system snapshotsUS20030182317Mar 22, 2002Sep 25, 2003Kahn Andy C.File folding techniqueUS20040024808Aug 1, 2002Feb 5, 2004Hitachi, Ltd.Wide area storage localization systemUS20040030668Aug 9, 2002Feb 12, 2004Brian PawlowskiMulti-protocol storage appliance that provides integrated support for file and block access protocolsUS20040078419Nov 2, 2001Apr 22, 2004Stephen FerrariSwitching systemUS20040093347Nov 13, 2002May 13, 2004Aditya DadaMechanism for comparing content in data structuresUS20060184587Apr 10, 2006Aug 17, 2006Federwisch Michael LSystem and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshotUS20070185928Jan 27, 2006Aug 9, 2007Davis Yufen LControlling consistency of data storage copiesUS20090006792Jun 28, 2007Jan 1, 2009Federwisch Michael LSystem and Method to Identify Changed Data BlocksUS20090030983May 30, 2008Jan 29, 2009Prasanna Kumar MalaiyandiSystem and method for non-disruptive check of a mirrorEP1003103A2Jun 2, 1994May 24, 2000Network Appliance, Inc.Write anywhere file-system layoutWO2000007104A1Jul 28, 1999Feb 10, 2000Network Appliance IncFile system image transferWO2001031446A1Oct 25, 2000May 3, 2001Network Appliance IncFile system image transfer between dissimilar file systemsNon-Patent CitationsReference1"rsync Unix Command Manual Page", version 2.4.1, Feb. 2000, 13 pages.2"Storage Management Mechanism for Managing Snapshot Pages", IBM Technical Disclosure Bulletin, IBM Corp., New York, US, vol. 35, No. 4B, Sep. 1, 1992, pp. 26-29.3Akyurek, Sedat, Placing Replicated Data to Reduce Seek Delays, Department of Computer Science, University of Maryland, UMIACS-TR-91-121, CS-TR-2746, Aug. 1991.4Bitton, Dina, Disk Shadowing, Proceedings of the 14th VLDB Conference, LA, CA 1988.5Chaudhuri, Surajit, et al., Self-Tuning Technology in Microsoft SQL Server, Data Engineering Journal 22, 2 1999 pp. 20-27.6Chutani, Sailesh, et al., The Episode File System, In Proceedings of the UNISEX Winter 1992.7Coyne, Robert A., et al., Storage Systems for National Information Assets, Proc. Supercomputing 92, Minneapolis, Nov. 1992, pp. 626-633.8Demaine et al., "Adaptive Set Intersections, Unions and Differences", Proceedings of the Annual ACM-SIAM Symposium on Discrete Algorithms, pp. 743-752, Year: 2000.9Finlayson, Ross S., et al., Log Files: An Extended File Service Exploiting Write-Once Storage Department of Computer Science, Stanford University, Report No. STAN-CS-87-1177, Sep. 1987.10Finlayson, Ross S., et al., Log Files: An Extended File Service Exploiting Write-Once Storage Department of Computer Science, Stanford University, Report No. STAN-CS-87-1177, Sep. 1987.11Gray, Jim, et al., The Recovery Manager of the System R Database Manager, ACM Computing Surveys, (13)2:223-2421981.12Hecht, Matthew S., et al. Shadowed Management of Free Disk Pages with a Linked List, ACM Transactions on Database Systems, 8/4. Dec. 1983, pp. 503-514.13Hitz et al., "TR3002 File System Design for an NFS File Server Appliance", 1-10, Network Appliance, Inc., Sunnyvale, CA, USA, 1995.14Howard, John, H. et al., An Overview of the Andrew File System, Carnegie Mellon Univesity, CMU-ITC-88-062 1988.15Howard, John, H. et al., Scale and Performance in a Distributed File System, ACM Trans. Computer System, 6(1), Feb. 1988 pp. 51-81.16Howard, John, H. et al., Scale and Performance in a Distributed File System, Carnegie Mellon University, CMU-ITC-87-068, Aug. 1987.17Kazar, Michael L., et al., DEcorum File System Architectural Overview, USENIX Summer Conference, Anaheim, California, 1990.18Kazar, Michael Leon, Synchronization and Caching Issues in the Andrew File System, Carnegie Mellon University, CMU-ITC-88-063.19Kemper, Alfons, et al., Performance Tuning for SAP R/3, Data Engineering Journal 22, 2 1999 pp. 33-40.20Kent, Jack et al., Optimizing Shadow Recovery Algorithms, IEEE Transactions on Software Engineering, 14(2): 155-168 , Feb. 1988.21Kistler, et al., Disconnected Operation in the Coda File System, ACM Transactions on Computer Systems, vol. 10, No. 1, Feb. 1992, pp. 3-25.22Lin et al., "System and Method for Transparent Data Replication over Migrating Virtual Servers", filed Apr. 24, 2007 as U.S. Appl. No. 11/739,239, 30 pages.23Lorie, Raymond, A. Physical Integrity in a Large Segmented Database, ACM Trans. Database Syst., vol. 2, Mar. 1977, pp. 91-104 .24Musser, David R., "Rationale for Adding Hash Table to the C++ Standard Template Library", Computer Science Department, Rensselaer Polytechnic Institute, Feb. 1995, 17 pages.25Orwant et al., "Mastering Algorithms with Perl", Publisher: O'Reilly Media, Inc., Pub Date: Aug. 20, 1999, ISBN-10: 1-565-92398-7.26Ousterhout, John et al., Beating the I/O Bottleneck: A Case for Log-Structured File Systems, Technical Report, Computer Science Division, Electrical Engineering and Computer Sciences, University of California at Berkeley, Oct. 30, 1988.27Partial European Search Report, Application No. EP 03251702, Munich, Leuridan, K., Jan. 4, 2005, 4 pages.28Partial European Search Report, Application No. EP 03251703, Munich, Leuridan, K., Jan. 4, 2005, 4 pages.29Patterson, D., et al., A Case for Redundant Arrays of Inexpensive Disks (RAID),-SIGMOD International Conference on Management of Data, Chicago, IL, USA, Jun. 1-3, 1988, SIGMOD Record (17)3:109-16 Sep. 1988.30Patterson, D., et al., A Case for Redundant Arrays of Inexpensive Disks (RAID),�SIGMOD International Conference on Management of Data, Chicago, IL, USA, Jun. 1-3, 1988, SIGMOD Record (17)3:109-16 Sep. 1988.31Patterson, D., et al., A Case for Redundant Arrays of Inexpensive Disks (RAID),-Technical Report, CSD-87-391, Computer Science Division, Electrical Engineering and Computer Sciences, University of California at Berkeley 1987.32Patterson, D., et al., A Case for Redundant Arrays of Inexpensive Disks (RAID),�Technical Report, CSD-87-391, Computer Science Division, Electrical Engineering and Computer Sciences, University of California at Berkeley 1987.33Peterson, Zachary Nathaniel Joseph, Data Placement for Copy-on-Write Using Virtual Contiguity, University of CA, Santa Cruz, Master's Thesis for the Department of Science in Computer Science, Sep. 2002.34Quinlan, Sean, A Cached WORM File System, Software-Practice and Experience, 21(12):1289-1299 1991.35Rosenblum, Mendel, et al., The Design and Implementation of a Log-Structured File System Jul. 24, 1991 pp. 1-15.36Rosenblum, Mendel, et al., The Design and Implementation of a Log-Structured File System, In Proceedings of ACM Transactions on Computer Systems, (10)1:26-52, Feb. 1992.37Rosenblum, Mendel, et al., The LFS Storage Manager, Computer Science Division, Electrical Engineering And Computer Sciences, Univ. of CA, presented at Summer '90 USENIX Technical Conference, Anaheim, CA Jun. 1990.38Rosenblum, Mendel, The Design and Implementation of a Log-Structured File System, 1992 pp. 1-93.39Schiefer, Berni, et al., DB2 Universal Database Performance Tuning, Data Engineering Journal 22, 2 1999 pp. 12-19.40Seltzer, Margo I., et al., Journaling Versus Soft Updates: Asynchronous Meta-Data Protection in File Systems, Proceedings of 200 USENIX Annual Technical Conference, Jun. 18-23, 2000.41Shasha, Dennis, Tuning Time Series Queries in Finance: Case Studies and Recommendations, Data Engineering Journal 22, 2 1999 pp. 41-47.42Sidebotham, Bob, Volumes: The Andrew File System Data Structuring Primitive, EEUG Conference Proceedings, Manchester, UK, Autumn 1986.43Subramanian, Muralidhar, et al., Performance Challenges in Object-Relational DBMSs, Data Engineering Journal 22, 2 1999 pp. 28-32.44Ting et al. "System and Method for Comparing Data Sets", U.S. Appl. No. 60/531,890, filed Dec. 23, 2003, 32 pages.45U.S. Appl. No. 10/776,057, filed Feb. 11, 2004 by Daniel Ting et al. for a System and Method for Comparing Data Sets, all pages.46Weikum, Gerhard, et al., Towards Self-Tuning Memory Management for Data Servers, Data Engineering Journal 22, 2 1999 pp. 3-11.47West, Michael, et al. The ITC Distributed File System: Prototype and Experience, Carnegie-Mellon University, Technical Report CMU-ITC-040, Mar. 1985.48Yemeni et al., "NESTOR: An Architecture for Network Self-Management and Organization", IEEE Journal on Selected Areas in Communications, vol. 18, No. 5, May 2000, pp. 758-766.49Zayas, Edward R., AFS-3 Programmer's Reference: Architectural Overview, Transarc Corporation, Pittsburgh, PA, 1.0 edition 1991.Classifications U.S. Classification711/162, 711/114International ClassificationG06F12/00Cooperative ClassificationG06F11/1464, G06F2201/84, G06F2201/82, G06F11/1456, G06F11/1458, G06F11/1612European ClassificationG06F11/16B2, G06F11/14A10HLegal EventsDateCodeEventDescriptionOct 21, 2013FPAYFee paymentYear of fee payment: 4Jan 18, 2011CCCertificate of correctionRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services