Hi Morgan, Jay
On 21/08/2009, at 2:36 AM, Morgan Tocker wrote:
For reference - DRBD lets you choose your algorithm as well.
While I agree with the comments about CRCs being weak, they are
awesomely fast. And Nehalem CPUs make them even faster:
http://en.wikipedia.org/wiki/SSE4#SSE4.2
But it's not about weak, it's about suitability. For our purpose, it's
fundamentally not suitable to use a CRC.
DRBD would use CRC to check the integrity of blocks of data, whether
they've become corrupted through transmission or in storage.
The use inside a RDBMS is fundamentally different: we want to know
whether two datasets are the same, either all of a table or a chunk of
it. But that's not what a CRC was designed to do. It's entirely valid
for two different blocks of data to come up with the same CRC.
A CRC detects bit-errors, particular patterns and numbers of flipped
bits and such, depending on which CRC algorithm is used.
I don't give a toss whether it's fast. It's unsuitable for what we're
talking about.
We don't want false positives, otherwise you can thnik your datasets
are in sync when they're not.
The "funny" thing is, this is recycling a discussion from late 80s
early 90s in FidoNet, and the "but it's fast" was also mentioned.
Can we please lay this to rest by noting that we should *NOT* be using
a CRC, but a fingerprint algorithm that's specifically designed to
allow comparison of two distinct data blocks and deciding whether
they're identical.
PPPPLEASE?
Cheers,
Arjen.
--
Arjen Lentz, Director @ Open Query (http://openquery.com)
Exceptional Services for MySQL at a fixed budget.
Follow our blog at http://openquery.com/blog/
OurDelta: free enhanced builds for MySQL @ http://ourdelta.org
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
