Hi, thanks for the review. On Thu, Oct 03, 2019 at 02:18:55PM +0200, Ard Biesheuvel wrote: > On Mon, 30 Sep 2019 at 15:12, David Sterba <dsterba@xxxxxxxx> wrote: > > The patch brings support of several BLAKE2 algorithms (2b, 2s, various > > digest lengths). The in-tree user will be btrfs (for checksumming), > > we're going to use the BLAKE2b-256 variant. It would be ideal if the > > patches get merged to 5.5, thats our target to release the support of > > new hashes. > > So this will be used as an alternative to crc32c, and plugged in at > runtime depending on the algo described in the fs superblock? Yes, exactly like that. One checksum for the whole filesystem, specificed by a number in the superblock item. > Is it performance critical? I'd put it that performance is important and blake2 has been selected as the fastest from the modern hashes (ie. sha3 was rejected for that reason). We're going to add cryptographically strong hashes (blake2, sha256) and a fast one (xxhash). So the users should choose what's the best for their usecase given the trade-offs. If the question is inspired by the current discussions around wireguard and library versions, we're fine with using the current API as it's reasonable for the hash algorithms. Improvements regarding reduction of the overhead would be welcome but is not important at the moment. I'll send v2 with the review comments addressed. Thanks. d.
