From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Dunlop Subject: Re: Adding compression/checksum support for bluestore. Date: Fri, 1 Apr 2016 14:56:11 +1100 Message-ID: <20160401035610.GA5671@onthe.net.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from smtp1.onthe.net.au ([203.22.196.249]:39938 "EHLO smtp1.onthe.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753001AbcDAD4O (ORCPT ); Thu, 31 Mar 2016 23:56:14 -0400 Content-Disposition: inline In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Allen Samuels Cc: Sage Weil , Igor Fedotov , ceph-devel On Wed, Mar 30, 2016 at 10:52:37PM +0000, Allen Samuels wrote: > One thing to also factor in is that if you increase the span of a > checksum, you degrade the quality of the checksum. So if you go with 128K > chunks of data you'll likely want to increase the checksum itself from > something beyond a CRC-32. Maybe somebody out there has a good way of > describing this quanitatively. I would have thought the "quality" of a checksum would be a function of how many bits it is, and how evenly and randomly it's distributed, and unrelated to the amount of data being checksummed. I.e. if you have any amount of data covered by an N-bit evenly randomly distributed checksum, and "something" goes wrong with the data (or the checksum), the chance of the checksum still matching the data is 1 in 2^n. Cheers, Chris