1. Technical Field
This invention is generally directed to a file system for use in a computer, embedded controller, or the like. More particularly, this invention is directed to a transaction based file system in which the integrity certain portions of the file system are verified during file system startup while the integrity of other portions of the file system are deferred.
2. Related Art
Computers, embedded controllers, and other microprocessor based systems are typically constructed from a variety of different hardware components. The hardware components may include a processor, I/O devices, human interface devices, etc. Additionally, such systems use memory storage units to maintain the data used in the system. The memory storage units may take on a variety of different forms including, but not limited to, hard disk drives, floppy disk drives, random access memory, flash memory, etc.
High-level application programs that are executed in such systems must often interact seamlessly with these hardware components, including the memory storage units. To this end, many systems run an operating system that acts as an interface between the application programs and the system hardware. File system software may be included as part of the operating system, or it may be provided as an ancillary software component that interacts with the operating system. In either instance, the file system software organizes the data within the memory storage units for ready access by the processor and the high-level application programs that the processor executes.
There are a number of different file system classifications since there are many ways to implement a file system. For example, a transaction based file system is one in which the file system is always maintained in a consistent state since all updates to the file system structure and the data are logged as transactions to a transaction file. More particularly, all updates to the file system are made as transactions within the transaction file, and the contents of the file system are dynamically re-constituted by successively applying all of the transactions that have been committed.
A transaction in the transaction file is either committed or it has not been completed. If the operation of the file system is interrupted, such as due to a power outage, for example, the state of the file system can be restored by consulting the contents of the transaction file. Any committed transactions are used by the file system, and any transactions that are not complete are rolled back, restoring the file system to the state it was in prior to the attempted update.
Restoration of the file system to a consistent state requires that the file system software execute a predetermined startup process. During a typical startup process, the integrity of each transaction stored in the transaction file is completely verified before it becomes part of the file system. Additional file system operations may also be executed during the startup process. The traditional manner in which transaction verification and other file system operations are performed after a file system interruption, however, is often sub-standard in that the operations are time, process and resource intensive.
A computer system that is used in implementing a transaction based file system is disclosed. The computer system includes a processor, random access memory that is accessible by the processor, and a persistent data storage device that is likewise accessible by the processor. The computer system also includes file system software. The file system software is executed by the processor and operates to manage the file data and the file system structure of the files stored on the persistent data storage device. Additionally, the file system software maintains a transaction file that includes a plurality of transaction records. Each of the transaction records has a header section and a data section. The header section of each transaction record includes one or more fields that are designated to store information corresponding to a file transaction that is represented by the transaction record. If the operation of the file system software is interrupted, the file system software resumes its execution using a startup process in which a reconstructed file system is generated in the random access memory. During system restart, the startup process skips verification of the data section of a transaction record when the transaction record meets one or more predetermined criterion. Instead, verification of the data section is deferred until some time after the file system startup process has completed. For example, the file system software may verify previously unverified data sections of each transaction record representing a given file upon a first or subsequent access of the given file, provided that the file access occurs after completion of the file system startup process.
In one example, the file system startup process may make a distinction between transaction records merely affecting file data versus transaction records that affect the metadata of the file system. As transactions are found during the startup process, the file system software may identify whether a transaction impacts file data or metadata. Since only the metadata is required to ensure that the file system is in a consistent state after startup, the transaction records relating to metadata may be selected as the only subset of transaction records that are subject to complete verification. Verification of other transaction records may, for example, be limited to a check of the information contained in the header section of each remaining transaction record. Once the file system startup process has been completed, any previously unverified transaction records or transaction record portions may be verified upon a first or subsequent access of the corresponding file.
The transaction file may be stored, for example, in flash memory. In such instances, the startup process may be further enhanced. For example, the startup process may limit its header information verification to the first transaction record of a sequence of transaction records in the same block of the flash memory device. Neither the header nor data sections of the trailing transaction records of the sequence are verified during startup and the startup process moves on to processing the transaction records of the next device block, if any. Still further, the startup process may check the header section information to determine whether the memory locations in a device block have been erased or retired. If the memory locations in the device block have been erased or retired, start a processing continues with the next device block. Again, any previously unverified transaction records or transaction record portions may be verified upon a first or subsequent access of the corresponding file once the file system startup process has been completed.
In one implementation, the file system software may maintain a file verification indicator that designates whether or not the integrity of each transaction file record for a given file has been completely verified. This file verification indicator is checked by the file system software the first time (or a subsequent time) that a file is accessed after the file system startup process has been completed. If the indicator shows that the transaction records of the file have not been completely verified, a verification of the transaction file records for the file may be executed at that time. To expedite this verification process, verification may be limited to the transaction records and transaction record sections that were not previously verified during the file system startup process.
Other systems, methods, features and advantages of the invention will be, or will become, apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the following claims.
The invention can be better understood with reference to the following drawings and description. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like referenced numerals designate corresponding parts throughout the different views.
Read only memory 20 may include operating system code 43 that controls the interaction between high-level application programs executed by the processor 15 and the various hardware components, including memory devices 20 and 35, the persistent storage unit 30, and the interface devices 40 and 45. The operating system code 43 may include file system software for organizing files stored on the persistent storage unit 30. Alternatively, the file system software may be provided as a separate software component that merely interacts with the operating system code 43. In the latter case, the code corresponding to the file system software may be stored in read only memory 20, persistent storage unit 30 or the like. When computer system 10 is networked with other computers and/or storage devices through I/O interface 40, the file system software may be stored remotely and downloaded to computer system 10 as needed.
The persistent storage unit 30 may take on any number of different forms. For example, the persistent storage unit 30 may take the form of a hard disc drive, floppy disk drive, etc. It may also be in the form of a non-rotating media device, such as non-volatile memory implemented in an integrated circuit format (e.g., flash memory, etc.). Still further, persistent storage unit 30 need not be limited to a single memory structure. Rather, the persistent storage unit 30 may include a number of separate storage devices of the same type (e.g., all flash memory) and/or separate storage devices of different types (e.g., one or more flash memory units and one or more hard disk drives).
The files stored in the persistent storage unit 30 include data that is interpreted in accordance with a predetermined format used by an application program or by the operating system code 43. For example, the data stored within a file may constitute the software code of an executable program, the ASCII text of a database record, data corresponding to transactions executed (or not executed) by computer system 10, etc.
In this exemplary system 10, the file system software 47 organizes the files stored on the persistent storage unit 30 using an inverted hierarchical structure.
The exemplary inverted hierarchical structure 50 includes five files 55, 60, 65, 70 and 75 at the highest level of the file system structure. Files 55, 60 and 65 are contained within directory 80 while files 70 and 75 are contained within directory 85. Accordingly, the file system software 47 organizes the file system so that the file system records representing child files 55, 60 and 65 point to the record for their parent directory 80. Similarly, file system records representing child files 70 and 75 point to the record for their parent directory 85.
At the next level of the exemplary inverted hierarchical structure 50, files 90 and 95 as well as directory 80 are contained within directory 100, while directory 85 is contained within directory 105. Accordingly, the file system software 47 organizes the file system so that file system records representing child directory 80 and child files 90 and 95 point to the record for their parent directory 100. Similarly, the file system record representing child directory 85 points to the record for its parent directory 105.
The root directory 110 may form the trunk of the inverted hierarchical structure 50. In this example, directories 100 and 105 and file 115 are contained within the root directory 110. Accordingly, the file system software 47 organizes the file system so that file system records representing child directories 100 and 105 and child file 115 point to the record for their parent directory 105.
One manner in which the file system software 47 may organize the records of the file system to implement an inverted hierarchical structure is shown in
In the example of
The inverted hierarchical structure of the file system may be implemented by employing a metafile record format in which each metafile record includes a pointer to the metafile record representing its parent directory.
Each metafile record may also include other information pertaining to the directory or file that the record represents. In the exemplary record format of record 135, a number of different information fields are employed. The information fields include a mode field 150, user identification field 155, group identification field 160, access time field 165, modified time field 170, created time field 175, file size field 180 and short name field 185. The mode field 150 is used to determine whether the file or directory represented by the record is a system file/directory, a hidden file/directory, a read only file/directory, etc. The user identification field 155 and group identification field 160 contain information relating to user and group ownership of the represented file or directory. The access time field 165, modified time field 170, and created time field 175 contain information relating to the time at which the represented file or directory was last accessed, the time at which the represented file or directory was last modified and the time at which the represented file or directory was created, respectively. The size field 185 contains information on the size of the file represented by the record and is zero for directory records. Finally, the short name field 185 contains ASCII characters representing the short text name of the corresponding file or directory. The length of the short name field 185 may be chosen, for example, to conform to the POSIX standard. Additionally, each record may include hash values and/or name sums that correspond to the short name. Such hash values and/or name sums may be used by the file system software 47 to quickly search for a particular directory and/or file record.
Each record in metafile 120 may also include a field for an extended record identifier 190. The extended record identifier 190 may be used as a file identifier that points to an extended record in the metafile 120. The extended record may contain further information for the file or directory represented by the record and is particularly useful in instances in which all of the information pertaining to a particular file or directory does not fit within the memory space allocated for a single metafile record.
In those instances in which the memory space allocated for two record entries is insufficient to hold all of the information pertaining to a file or directory, the extended record 195 may point to yet a further extended record using its own extended record identifier, such as the one included in field 205 of record 195. Although the format for the further extended record pointed to by extended file identifier 125 is not shown, the further extended record may likewise include a parent record identifier that points back to record 195.
The type of information included in an extended record may vary between file systems. In
In the foregoing example, the extended records used by the file system are stored in metafile 120. However, the extended records and any further extended records may alternatively be stored in a separate metafile, multiple metafiles, etc. The separate metafile(s) need not share the same storage medium with metafile 120 nor with each other. Rather, the metafiles may be stored in different storage media accessible to processor 15. Even the basic metafile records (directory and file records that do not have corresponding extended records) may be distributed among multiple files and/or multiple storage media. As such, although the metafile records of the exemplary system are stored in a single metafile, the metafile may alternatively be in the form of many individual files on the same or different storage media.
By organizing the files and directories of computer system 10 in an inverted hierarchical structure, it becomes possible to realize one or more file system advantages. For example, the file system is capable of being implemented in any manner in which typical file and directory transactions (i.e., moving a file/directory, deleting a file/directory, creating a file/directory, copying a file/directory) are accomplished atomically as a change, addition or deletion of a single metafile record. In such an implementation, for example, the file/directory represented by record 135 may be moved to another directory in the hierarchy merely by changing the parent identifier 140 so that it points to the metafile record for the new parent directory. This may be accomplished with a single write operation to record 135 in the metafile 120.
The foregoing inverted hierarchical structure may be employed to optimize a transactional or log-based system. An exemplary transactional or log-based system may be constructed from the components shown in
One manner in which a transaction record 225 may be formatted for use in computer system 10 is shown in
Each of the sub-fields of header field 230 has a meaning to the file system software 47. In this example, the transaction sequence field 240 is a monotonically increasing transaction identifier that is assigned by the file system software 47. When a new transaction record is added to the transaction file 220, the value stored in the transaction sequence field 240 of the new record may be increased by a predetermined amount over the value of the transaction sequence field of the chronologically preceding transaction record. Consequently, transaction records having larger transaction identifier values are considered to have been added to the transaction file 220 later in time than transaction records having lower transaction identifier values. This chronological sequencing of the transactions, as represented by the value of the transaction sequence field 240 (and, in certain circumstances, the position of the transaction record within a block of the transaction file 220), allows the file system software 47 to apply (i.e., commit) the transactions in the proper order to maintain the integrity of the file system contents. Other ways of keeping track of the chronological sequencing of the transactions may also be used.
File system software 47 uses the transaction status field 250 to determine whether the transaction of a transaction record 225 has been committed. Once a transaction has been committed, further alteration of the committed transaction record 225 may be inhibited by the file system software 47. This ensures consistency of the file system and also allows the file system to store the transaction file 220 in, for example, write-once media, flash media, or the like.
The file identification field 245 of header 230 identifies the file that is affected by the transaction record 225. The format for the file identification field 245 may be selected so that it is the same as the file identifiers used in the metafile records. The cluster high field 255 and cluster low field 260 are used by the file system software 47 to determine the starting address (or offset) at which the data 235 is to be written into the identified file while the number of clusters field 265 is used to determine how many clusters of the identified file are to be overwritten by the data 235.
As noted above, persistent storage unit 30 may include one or more flash memory devices. Flash memory devices store information in logic gates, called “memory cells,” each of which typically stores one bit of information. More recent advances in flash memory technology have also enabled such devices to store more than 1 bit per cell, sometimes referred to as multi-level cell devices. Additionally, flash memory is non-volatile, which means that the contents of memory cells are not lost when power is withdrawn from the device.
Although flash device technology is continuously evolving, dominant technologies include NAND flash memory and NOR flash memory. NOR flash devices and NAND flash devices generally differ in the type of logic gate used for each storage cell. An exemplary logical architecture 270 of one type of NAND flash memory device 275 is shown in
NOR flash devices have an architecture similar to that shown in
The data area 295 and spare area 300 are typically set to specific sizes in both NOR and NAND flash devices. For example, each page 290 of the exemplary NAND flash device 270 of
Flash memory devices, such as NAND flash device 270, typically perform erase operations on an entire block 280 of memory at a time. An erase operation sets all bits within the block 280 to a consistent state, normally to a binary “1” value. Programming operations on an erased block 280 of flash device 270 can only change the contents of an entire page 290 (although NOR flash devices may be programmed in a slightly different manner). Once a page 290 of a NAND flash device is programmed, its state cannot be changed further until the entire block 280 is erased again. Reading of the contents of flash device 275 also occurs at the page level.
An alternative arrangement in which there is a one-to-one correspondence between each logical page 315 and a physical page 290 of flash device 270 is shown in
The sequence identifiers for the transaction records 310 stored in the same device block 290 may have the same values. In such instances, the sequence identifier provides chronological information that may be used to compare the time relationship between the transaction records of different device blocks. Chronological information on the transaction records 310 stored in the same block can be derived from the offset location of the transaction record 310 within the block 290, with later occurring transaction records 310 occurring at larger offsets.
After the computer system 10 has been started or powered on, the integrity of the file system may be verified by generating a reconstructed version of the file system in random access memory 35. The reconstructed file system, shown generally at 330 of
One manner of generating the extents table 340 is shown in
Generation of the extents table 340 may commence at step 345 of
As the file system software 47 scans the blocks of the transaction file 220 for transactions, the file system software may encounter a block that has been erased as a result of transactions that have been retired, or because the blocks have not yet been assigned for use in the file system. The transaction header may be structured so that there are no valid transactions that will have all of the bits of the header set to the erased value, typically a binary “1”. As the file system software 47 scans the blocks of the transaction file 220, any transaction in which the header indicates an erased block may be skipped. This header invariant may be enforced by using a single bit as a flag to indicate the transaction is in use by the file system when it is the inverse of the erase value. Upon finding such an erase signature value in a transaction header, scanning of the remaining pages in the block is skipped thereby saving the time that would otherwise be used to access the erased pages. The overall system startup time is correspondingly decreased.
The organization of an exemplary block array 355 is shown in
At step 380 of
Each transaction list record 390 of the transaction list table 385 may have the same record length and include the same record fields. The exemplary fields used in records 390 of
At step 415, the records 360 of block array 355 are sorted based on the values stored in the sequence fields 365. This operation is performed to place the records 390 of the transaction list table 385 in chronological order (i.e., the order in which the corresponding transactions are to be applied to the files of the file system).
A temporary file 440 storing file node information corresponding to the transaction records of the file system may then be generated in RAM 35 using the sorted records of block array 355 and transaction list table 385. To this end, a basic record corresponding to the root directory of the file system is first added to temporary file 440. The information used to generate the root directory node in temporary file 440 may be obtained from the record corresponding to the root directory file stored in metafile 120.
A logical representation of one manner of arranging the file node records in temporary file 440 is shown generally at 445 of
At step 420, each of the sorted records 360 and 390 of the block array 355 and transaction list table 385 are traversed to determine whether or not the temporary file 440 includes a file node record 450 corresponding to the file identifier stored in file identifier/idx field 410. If a file node record 450 with the same file identifier as the transaction record 390 is not found in the temporary file 440, a new file node record 450 is created at step 430. Once a file node record 450 corresponding to the transaction list record 390 exists in temporary file 440, the transaction list record 390 may be linked into a list of transactions for the file node record 450. In this example, the transaction list record 390 is linked into the list of transactions for the file node record 450 at step 435 of
Once all of the transaction list records of the transaction list table 385 have been linked in the proper manner with the corresponding file node records, the transaction list records for each file node are traversed at step 485 to remove any transaction list records that reference uncommitted and/or bad file transactions. Removal of such transaction list records may be accomplished in a variety of different manners. For example, the file system software 47 may check the status field of the last occurring transaction to determine whether or not it was committed. If the transaction has been committed, the corresponding record in the transaction list table 385 is left undisturbed. If the transaction has not been committed, however, the corresponding record in the transaction list table 385 is removed or otherwise ignored.
To expedite this type of transaction commitment checking, the file system software 47 only needs to ensure that the last occurring transaction has been committed. Commitment checking of all other records may be skipped since only the last occurring transaction is impacted by a power failure, improper system shutdown, or the like. By skipping commitment checking of all other records, the time required for system startup may be substantially reduced.
Although it is shown as part of a linear sequence, step 485 may be executed as each transaction list record is processed for incorporation in the corresponding file node. For example, file system software 47 may check the status information included in the header of each transaction record to determine whether the transaction has been committed. This check may occur as each transaction record is used to populate the corresponding transaction list record. Once the file system software 47 finds a transaction that has not been committed, no further processing of the transaction list table 385 in steps 420 through 485 of
At step 490, entries are generated in extents pool 340 for each of the file nodes. One manner in which this may be accomplished is shown in
The data used to populate the records of the extents pool 340 may be derived, at least in part, from the data stored in the transaction list table 385. In the example shown here, the extents pool 340 is a more compact form of the transaction list table 385. To this end, file system software 47 may combine transaction list records having contiguous data into a single extents record entry if the transaction list records are part of the same file node. Similarly, there is no further need to maintain the block array 355 in RAM 35. Therefore, block array 355 may be discarded from RAM 35.
The integrity of the transactions in the transaction file 220 may be checked during the execution of the various steps used to generate extents pool 340. For example, integrity checking of the transaction records may be executed during either steps 350 or 380 of
To decrease the startup time of the computer system 10, error checking techniques may be limited to the information included in the header for certain transactions. As transactions are found during the startup process shown in
Any startup verification of the transaction records may be further optimized by limiting error checking solely to the first transaction header of a series of sequential transactions. During startup scanning of the transaction file 220, when a transaction header is found that indicates that a number of sequential transaction records for the same file follow, verification of the headers of the trailing transactions in the sequence may be skipped once the header for the first transaction record of the sequence has been verified. Scanning and verification of header information may then resume with the next block following the last of the trailing transactions.
The next broad step in generating the reconstructed file system 330 in RAM 35 is the construction of the regenerated file hierarchy 335. In this example, the regenerated file hierarchy 335 is comprised of both file and directory node records. An exemplary format for a directory node record is shown generally at 520 of
Directory node record 520 includes a number of different fields that are used by the file system software 47. More particularly, directory node record 520 may include a sibling field 530, a file identifier field 535, a parent identifier field 540, a child field 545 and a directory named field 550. Similarly, file node record of
Since the data contained in the records of metafile 120 is used in the construction of the regenerated file hierarchy 335, the manner in which the metafile records are arranged in the metafile 120 will have an impact on the system startup performance. To this end, the records of metafile 120 are arranged in a single metafile as contiguous records having the same length and are all stored in the same storage media. This arrangement enhances the speed with which the file system software 47 may access the metafile data and reduces the amount of processing that is required for such access.
One sequence of steps that may be used to populate the fields for each file node record 525 and directory node record 520 of the regenerated file hierarchy 335 is shown in
At step 585, the fields for the newly created record are populated using the attributes for the file/directory that are found in the metafile 120. If the newly created record corresponds to a directory node, the parent identifier field 540 and directory name field 550 are populated using the data in the parent file identifier and short name fields of the corresponding record in metafile 120. If the newly created record corresponds to a file node, the name sum field 570 may be populated using data that is directly stored or derived from the file name data of the corresponding record in metafile 120. The extents index field 565 is populated using the data found in the extents index field 487 of the corresponding file node record 450 (see
If the newly created file corresponds to a directory node, a search through the regenerated file hierarchy 335 is undertaken at step 590 to determine whether the parent node exists. If the parent node does not exist, a directory record corresponding to the parent node is added to the regenerated file hierarchy 335.
At step 595, the newly generated file/directory record is linked into the tree structure for the parent directory node. If the child field 545 of the newly generated file/directory record indicates that the parent directory has no children, the value of the child field 545 of the parent directory record is reset to point to the newly generated file/directory record and the sibling field 555 or 530 of the newly generated file/directory record is set to indicate that the newly generated file/directory record does not have any siblings. If the child field 545 of the parent node record indicates that the parent directory node has children, the sibling field 565 or 530 of the newly generated file/directory record is set to point to the existing child of the parent directory and the child field 545 of the parent directory is set to point to the newly generated file/directory record. If the newly generated file/directory record corresponds to a directory node, the parent identifier field 540 of the newly generated directory record is set to point to the parent directory node.
At step 600, the file system software 47 recursively ascends the parent nodes, beginning with the parent directory of the newly generated file/directory record, and executes a series of processing steps until the root node is reached. At this point, the parent directory node of the newly generated file/directory record may be referred to as the current directory node. In the exemplary process shown in
If the check executed at steps 605 and 610 indicate that there is a directory record in the regenerated file hierarchy 335 that corresponds to parent node of the current directory, then the current directory node is linked into the generalized tree structure of the parent directory node at step 630. To this end, the parent identifier field 540 of the current node is set to point to the location of the parent node record in the regenerated file hierarchy 335. The sibling field 530 of the current directory node is set to point to the same record as pointed to by the child field 545 of the parent node record. Finally, the child field 545 of the parent directory node is set to point to the location of the current directory node.
At step 635, the file system software 47 checks to determine whether the recursive directory processing is completed. In this example, the recursive directory processing is completed when the processing a sends to the root node, which has a unique and recognizable file identifier. If the root node has been reached at step 635, processing of the next file record entry in metafile 120 is begun at step 640, which returns control of the processing back to step 575. If the root node has not been reached at step 635, then processing of the next parent node in the ascending file/directory hierarchy is repeated beginning at step 605.
One manner of accessing data in the transaction file 220 of persistent storage unit 30 using the reconstructed file system 330 is also illustrated in
As noted above, complete verification of the integrity of a file is not performed during startup so that startup processing may be expedited. Instead, the file system software 47 may defer complete verification or verification of previously unverified portions of a transaction record corresponding to a given file until the first or subsequent time that the given file is accessed. To this end, the file system software 47 may maintain a table indicating whether or not the integrity of each transaction file record for a given file has been completely verified. Alternatively, the file system software 47 may use one or more bits of each file node record in the regenerated file hierarchy 335 to indicate whether the integrity of the transaction records for the file have been completely verified. This file verification indicator is checked by the file system software 47 the first time (or a subsequent time) that a file is accessed after the file system startup process has been completed. If the indicator shows that the transaction records of the file have not been completely verified, a verification of the transaction file records may be executed at that time. To expedite the verification process, verification of the transaction file records may be limited to the particular sections of the records that were not previously verified. For example, since the headers of most of the transaction records for the file may already have been checked during the file system startup process, the file system software need only verify the integrity of the data portions of each transaction record for the file. The verification processes may include one or more CRC processes, one or more ECC processes, etc. As shown in
While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.
Number | Name | Date | Kind |
---|---|---|---|
4882703 | Nicolai | Nov 1989 | A |
4926317 | Wallach et al. | May 1990 | A |
4945475 | Bruffey et al. | Jul 1990 | A |
5187786 | Densmore et al. | Feb 1993 | A |
5201044 | Frey et al. | Apr 1993 | A |
5222217 | Blount et al. | Jun 1993 | A |
5369757 | Spiro et al. | Nov 1994 | A |
5375233 | Kimber et al. | Dec 1994 | A |
5454103 | Coverston et al. | Sep 1995 | A |
5455944 | Haderle et al. | Oct 1995 | A |
5530849 | Hanushevsky et al. | Jun 1996 | A |
5726989 | Dokic | Mar 1998 | A |
5765172 | Fox | Jun 1998 | A |
5774715 | Madany et al. | Jun 1998 | A |
5806085 | Berliner | Sep 1998 | A |
5897661 | Baranovsky et al. | Apr 1999 | A |
5960436 | Chang et al. | Sep 1999 | A |
5983293 | Murakami | Nov 1999 | A |
5995980 | Olson et al. | Nov 1999 | A |
6058400 | Slaughter | May 2000 | A |
6175900 | Forin et al. | Jan 2001 | B1 |
6185663 | Burke | Feb 2001 | B1 |
6286013 | Reynolds et al. | Sep 2001 | B1 |
6292808 | Obermarck et al. | Sep 2001 | B1 |
6324637 | Hamilton | Nov 2001 | B1 |
6356863 | Sayle | Mar 2002 | B1 |
6377992 | Plaza et al. | Apr 2002 | B1 |
6389427 | Faulkner | May 2002 | B1 |
6389513 | Closson | May 2002 | B1 |
6396421 | Bland | May 2002 | B1 |
6412042 | Paterson et al. | Jun 2002 | B1 |
6467021 | Sinclair | Oct 2002 | B1 |
6509850 | Bland | Jan 2003 | B1 |
6571259 | Zheng et al. | May 2003 | B1 |
6584582 | O'Connor | Jun 2003 | B1 |
6591376 | VanRooven et al. | Jul 2003 | B1 |
6606628 | Monsen et al. | Aug 2003 | B1 |
6661357 | Bland | Dec 2003 | B2 |
6675177 | Webb | Jan 2004 | B1 |
6732124 | Koseki et al. | May 2004 | B1 |
6748491 | Rodriguez | Jun 2004 | B2 |
6754696 | Kamath et al. | Jun 2004 | B1 |
6845401 | Papadopoulos et al. | Jan 2005 | B1 |
6856993 | Verma et al. | Feb 2005 | B1 |
6922708 | Sedlar | Jul 2005 | B1 |
7003619 | Moore et al. | Feb 2006 | B1 |
7047257 | Fletcher et al. | May 2006 | B2 |
7096248 | Masters et al. | Aug 2006 | B2 |
7139752 | Broder et al. | Nov 2006 | B2 |
7181463 | Moore et al. | Feb 2007 | B2 |
7191185 | Dweck et al. | Mar 2007 | B2 |
7349927 | Kanai et al. | Mar 2008 | B2 |
7383286 | Hamanaka et al. | Jun 2008 | B2 |
7529784 | Kavuri et al. | May 2009 | B2 |
7555483 | Maeda et al. | Jun 2009 | B2 |
7565452 | Freiburg et al. | Jul 2009 | B2 |
20010044798 | Nagral et al. | Nov 2001 | A1 |
20020048223 | Ota et al. | Apr 2002 | A1 |
20020120634 | Min et al. | Aug 2002 | A1 |
20020143862 | Peterson | Oct 2002 | A1 |
20020156840 | Ulrich et al. | Oct 2002 | A1 |
20020156937 | Wong et al. | Oct 2002 | A1 |
20020156938 | Wong et al. | Oct 2002 | A1 |
20020165942 | Ulrich et al. | Nov 2002 | A1 |
20020174295 | Ulrich et al. | Nov 2002 | A1 |
20030065682 | Nakajima | Apr 2003 | A1 |
20030070001 | Belknap et al. | Apr 2003 | A1 |
20030115227 | Guthery | Jun 2003 | A1 |
20030140210 | Testardi | Jul 2003 | A1 |
20030163594 | Aasheim et al. | Aug 2003 | A1 |
20030225585 | Miller et al. | Dec 2003 | A1 |
20040064500 | Kolar et al. | Apr 2004 | A1 |
20040114589 | Alfieri et al. | Jun 2004 | A1 |
20040215600 | Aridor et al. | Oct 2004 | A1 |
20040236793 | Kanai et al. | Nov 2004 | A1 |
20050050073 | Demiroski et al. | Mar 2005 | A1 |
20050091229 | Bali et al. | Apr 2005 | A1 |
20050091287 | Sedlar | Apr 2005 | A1 |
20050117885 | Lee et al. | Jun 2005 | A1 |
20050144526 | Banko | Jun 2005 | A1 |
20050149525 | Verma et al. | Jul 2005 | A1 |
20050210507 | Hawkins et al. | Sep 2005 | A1 |
20050240588 | Siegel et al. | Oct 2005 | A1 |
20050246362 | Borland | Nov 2005 | A1 |
20050251540 | Sim-Tang | Nov 2005 | A1 |
20050256845 | Jen et al. | Nov 2005 | A1 |
20050273486 | Keith, Jr. | Dec 2005 | A1 |
20060015431 | Bugaj et al. | Jan 2006 | A1 |
20060021057 | Risan et al. | Jan 2006 | A1 |
20060074851 | Nagai et al. | Apr 2006 | A1 |
20060117056 | Havewala et al. | Jun 2006 | A1 |
20060136529 | Pudipeddi et al. | Jun 2006 | A1 |
20060190469 | Kathuria et al. | Aug 2006 | A1 |
20060195480 | Spiegelman et al. | Aug 2006 | A1 |
20060206538 | Veazey | Sep 2006 | A1 |
20060242179 | Chen et al. | Oct 2006 | A1 |
20060253502 | Raman et al. | Nov 2006 | A1 |
20060277183 | Nichols et al. | Dec 2006 | A1 |
20070005560 | Dodge | Jan 2007 | A1 |
20070005615 | Dodge | Jan 2007 | A1 |
20070005627 | Dodge | Jan 2007 | A1 |
20070005874 | Dodge | Jan 2007 | A1 |
20070005894 | Dodge | Jan 2007 | A1 |
20070073937 | Feinberg et al. | Mar 2007 | A1 |
20070103984 | Kavuri et al. | May 2007 | A1 |
20070113120 | Dodge | May 2007 | A1 |
20070185879 | Roublev et al. | Aug 2007 | A1 |
20070198746 | Myllyla et al. | Aug 2007 | A1 |
20080033777 | Shukoor | Feb 2008 | A1 |
20080052323 | Dodge et al. | Feb 2008 | A1 |
20080052329 | Dodge et al. | Feb 2008 | A1 |
20080059510 | Cardamore et al. | Mar 2008 | A1 |
20080126936 | Williams | May 2008 | A1 |
20080147747 | Cardamore | Jun 2008 | A1 |
20080228843 | Dodge et al. | Sep 2008 | A1 |
20090037651 | Gorobets | Feb 2009 | A1 |
20090265793 | Risan et al. | Oct 2009 | A1 |
Number | Date | Country |
---|---|---|
1289966 | Apr 2001 | CN |
1567256 | Jan 2005 | CN |
1705935 | Dec 2005 | CN |
0 410 210 | Jan 1991 | EP |
454340 | Oct 1991 | EP |
0 588 488 | Mar 1994 | EP |
1 089 176 | Apr 2001 | EP |
62-186361 | Aug 1987 | JP |
06-139124 | May 1994 | JP |
2006-0009717 | Feb 2006 | KR |
10-2006-00223387 | Mar 2006 | KR |
WO 0014632 | Mar 2000 | WO |
WO 0217140 | Feb 2002 | WO |
WO 2006-061454 | Jun 2006 | WO |
Number | Date | Country | |
---|---|---|---|
20070005614 A1 | Jan 2007 | US |