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.liu@xxxxxxxxxx> 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? I could see this possibly being useful for having fewer false positives when using the inbuilt checksums for purposes of dedup. Hugo. -- Hugo Mills | That's not rain, that's a lake with slots in it hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: 65E74AC0 |
Attachment:
signature.asc
Description: Digital signature
