percona-discussion team mailing list archive

[Baron Schwartz <baron@xxxxxxxxx>]

On Tue, Apr 28, 2009 at 7:59 PM, Arjen Lentz <arjen@xxxxxxxxxxxxx> wrote:
> Hi Mark, Vadim,
>
> On 28/04/2009, at 10:58 PM, MARK CALLAGHAN wrote:
>>
>> Have you seen this bug report?
>> http://bugs.mysql.com/bug.php?id=19975
>>
>> Also, have you done any experiments with the page checksum method for
>> InnoDB to make it faster or to change the algorithm and I realize that
>> changing the algorithm has a huge impact on deployed servers. Once you
>> begin doing a lot of IO on fast SSD systems, you will burn a lot of
>> CPU time doing checksum validation.
>
>
> Note in buf/buf0buf.c that the old checksum is still used as well as the
> new.
> Would it be possible to remove the old, at least?

That seems like it would be a nice improvement.

> And what is actually going on in include/ut0rnd.ic with the homegrown foo?
> ut_fold_binary() is the function used for generating the checksum.
> What kind of bit errors does the homegrown stuff detect, how does it hold up
> to say CRC in terms of catching problems, and computational
> complexity/speed?
> Look, if we were to change algorithms... CRCs can be optimised, and there
> are I believe also newer algorithms that can be even less computationally
> intensive.

Yeah, but... changing checksum would instantly result in all pages
being "corrupt", no?

> But there's an additional issue with the whole checksum foo. The checksum is
> right next to the data, and while CRCs are decent at detecting corruption,
> the proximity can also hide some occurrances. ZFS has the nifty trick of
> storing checksums separately, and I think that's quite brilliant. Not saying
> it's easy to do for InnoDB or even if it's desirable - just want to put it
> out there so we can discuss.

I think it's a really good design.  It seems "hard" at this stage in
InnoDB's life, though.

What about PBXT or Maria?  I don't even know if they checksum data.