Re: Transparent compression in the FS

From: John Bradford
Date: Fri Oct 17 2003 - 03:11:59 EST


> > 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.
> >
> > 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.
>
> It doesn't really matter that the hash collision is /less/ likely to ruin data
> than something in hardware as it adds an /extra/ layer of possible corruption,
> so you have a net gain in the possible corruption of your data. Now, if you
> could write it so that there was /no/ possibility of data corruption, than it
> would be much more acceptable as it wouldn't add any extra likeliness of
> corruption than already exists.

Comparing the reliability of the hash function to the reliability of
hardware is an apples to oranges comparison. Far more interesting
would be to compare the correlation between reliability of each of
them to the input data.

I.E.:

The hash function scores 100% on this - certain patters will _always_
trigger a fault. Once you find a way to make it corrupt data, it will
be 100% reproducable using the same dataset.

The hardware will typically score less than 100% - certain patterns of
data in memory are more likely to make a weak RAM chip flip a bit, we
have seen many examples of that where a machine dies quickly running
memtest86, but will run Linux apparently fine for at least a while.
However, other things such as the temperature affect this. It's rare
to find a memory access pattern that will 100% reliably lock up a
machine in exactly the same way.

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/