On Tue, Apr 5, 2016 at 10:50 PM, Allen Samuels <Allen.Samuels@xxxxxxxxxxx> wrote: > 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. It would depend in which layer the corruption was introduced. crc32 is in the ethernet frame, AFAIK. We've observed corrupted packets where the TCP checksum validated but the data was clearly corrupted [1]. Ceph messenger crc32c helped in that case, but from this discussion it's not strong enough to detect all levels of corruptions in long messages. > 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 :) I was referring to deep scrub of the non-bluestores. Perhaps FileStore deep-scrub needs to be stronger than crc32c. -- Dan [1] http://cds.cern.ch/record/2026187/ -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
