Pre-Grant Publication Number: 20110029497
Please help the USPTO examine the application by evaluating the relevance of the publicly submitted prior art to the patent application.
Peer To Patent forwards the Top 10 most relevant prior art submissions and their annotations to the USPTO.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Review this prior art and click on the thumbs up (or down) to indicate whether this submission should be forwarded to the USPTO.
If you login then you can add an annotation by typing in the box at the bottom of the screen to comment on the relevance of the prior art to the claims of the patent application.
Prior Art Detail
Summary / Description
| Summary / Description | Article describing data deduplication. |
Basic Information
| Type of Prior Art | Online Publication |
| URL | http://www.backupcentral.com/mr... |
| Author/Creator | W. Curtis Preston |
| Title | In-line or post-process de-duplication? |
| Publication Date | August 24, 2007 |
| Publisher | backupcentral.com |
| Directions to Document Location | |
| Additional Information | |
Notes / To Do
| Notes | |
Excerpt
Excerpt A block of data comes into the appliance (as part of a larger stream of data from a backup). While it's in RAM, the appliance does its magic to figure out whether it's seen that block before. If it has seen it before, it writes a pointer somewhere saying that it's seen it again. If it hasn't seen the block of data before, it writes the new block. Job complete.
This method allows most of the hard work to be done in RAM, which minimizes I/O overhead. The only disk operation that's done 100% of the time is the hash lookup (except for an in-line vendor that can keep their hash in RAM). (Some products must also do a read of the block the new block apparently matches to in order to do a bit-level verification that the two blocks are the same before discarding the new block.) 90% or the time (when the block matches a block already seen -- assuming a 10:1 de-dupe ratio), it requires one write to the disk to update the hash table, and that's it. It just throws away the redundant block and never writes it to disk. 10% of the time (when it's a new, unique block), it requires one write to disk and one write to the hash table.
|
Relevance
Claims
1
Relevance
Publication reads on claim 1.
Publication reads on claim 1.
Claim Chart
All
0 days left
