Messages in this thread | | | Date | Thu, 16 Oct 2003 19:19:48 -0700 | From | jw schultz <> | Subject | Re: Transparent compression in the FS |
| |
On Thu, Oct 16, 2003 at 09:32:45PM -0400, jlnance@unity.ncsu.edu wrote: > On Thu, Oct 16, 2003 at 04:04:48PM -0700, jw schultz wrote: > > > > The idea of this sort of block level hashing to allow > > sharing of identical blocks seems attractive but i wouldn't > > trust any design that did not accept as given that there > > would be false positives. > > But at the same time we rely on TCP/IP which uses a hash (checksum) > to detect back packets. It seems to work well in practice even > though the hash is weak and the network corrupts a lot of packets. > > Lots of machines dont have ECC ram and seem to work reasonably well.
That is because most of the errors (which are few) get lost in the noise of BSODs or are trivial data errors. Can you tell whether your application crashed because it had a bug or because a bit in memory flipped? Is tiis a typm or did a bit or two flip on this email message? There is a big difference between single bit errors and having an entire block of a file be wrong.
> It seems like these two are a lot more likely to bit you than hash > collisions in MD5. But Ill have to go read the paper to see what > Im missing.
There is a big difference between the probability of any random pair of blocks getting a false positive, much less a given block with some corruption still hashing the same and a false positive between one block and any of millions of others.
It is a bit like the difference in odds between you winning at this weeks lotto and anyone winning this week. Are you willing to bet that nobody wins this weeks lotto? Would you stake your life savings on it?
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws
Remember Cernan and Schmitt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |