-------- Original Message --------
Subject: Re: [RFC PATCH] Btrfs: add sha256 checksum option
From: Hugo Mills <h...@carfax.org.uk>
To: Chris Mason <c...@fb.com>
Date: 2014年11月25日 04:58
On Mon, Nov 24, 2014 at 03:07:45PM -0500, Chris Mason wrote:
On Mon, Nov 24, 2014 at 12:23 AM, Liu Bo <bo.li....@oracle.com> wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to
crc32c for
performance purposes.
As crc32c is sort of weak due to its hash collision issue, we need
a stronger
algorithm as an alternative.
Users can choose sha256 from mkfs.btrfs via
$ mkfs.btrfs -C 256 /device
Agree with others about -C 256...-C sha256 is only three letters more ;)
What's the target for this mode? Are we trying to find evil people
scribbling on the drive, or are we trying to find bad hardware?
You're going to need a hell of a lot more infrastructure to deal
with the first of those two cases. If someone can write arbitrary data
to your storage without going through the filesystem, you've already
lost the game.
I don't know what the stats are like for random error detection
(probably just what you'd expect in the naive case -- 1/2^n chance of
failing to detect an error for an n-bit hash). More bits likely are
better for that, but how much CPU time do you want to burn on it?
Agree with this, sha256's extra CPU usage seems not so worthy.
About the csum algorithm, personally I prefer algorithm with better
error detection,
not only the integration about the whole data, but the range where the
error lies in.
If btrfs can know, for example which 4K or 2K block the error lies in,
it can drops only the range of data,
not the whole tree block, which can do great help for later btrfsck things.
In this point of view, 4 crc32 for 16K leaf/node (1 crc32 for 4K) may be
more productive than single sha256.
Thanks,
Qu
I could see this possibly being useful for having fewer false
positives when using the inbuilt checksums for purposes of dedup.
Hugo.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
