Re: Transparent compression in the FS

[jw schultz <jw@pegasys.ws>]

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