If messenger is doing CRC-32, then it's probably not yielding as much value as you would like. That's because the NIC has ALREADY done a CRC-32 on data over the wire. Doing the extra CRC in software will certainly help verify that the NIC, PCIe bus, DRAM system is working well -- but the real value is an end-to-end integrity check of the software (i.e., most likely failure is a software failure). You don't need a CRC for that. However, CRC is cheap enough not to worry. As for scrub, it's different -- presumably you're already downstream of the HW ECC and whatever strong checksums you put on BlueStore. Totally different discussion. Plus, many of the "failure" modes here aren't actual failures. In other words some of the failures don't deliver corrupt data, they just rebuild data that was already good :) Allen Samuels Software Architect, Fellow, Systems and Software Solutions 2880 Junction Avenue, San Jose, CA 95134 T: +1 408 801 7030| M: +1 408 780 6416 allen.samuels@xxxxxxxxxxx > -----Original Message----- > From: Dan van der Ster [mailto:dan@xxxxxxxxxxxxxx] > Sent: Tuesday, April 05, 2016 5:58 AM > To: Allen Samuels <Allen.Samuels@xxxxxxxxxxx> > Cc: Chris Dunlop <chris@xxxxxxxxxxxx>; Sage Weil <sage@xxxxxxxxxxxx>; > Igor Fedotov <ifedotov@xxxxxxxxxxxx>; ceph-devel <ceph- > devel@xxxxxxxxxxxxxxx> > Subject: Re: Adding compression/checksum support for bluestore. > > On Tue, Apr 5, 2016 at 1:58 AM, Allen Samuels > <Allen.Samuels@xxxxxxxxxxx> wrote: > > It's now clear that if you double the data size, you need to add one bit to > your checksum to compensate. > > Slight parenthesis: let's not forget that the messenger and OSD deep scrubs > use crc32c for potentially very large chunks of data. If bluestore gets strong > checksums we should try be consistent throughout the code base. > > -- > Dan ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
