RepoMirrors
/
btrfs-progs
mirror of https://github.com/kdave/btrfs-progs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

btrfs-progs: docs: checksumming editing

This commit is contained in:
(@silopolis) 2024-10-23 10:17:09 +00:00 committed by David Sterba
parent 499a0493b3
commit b5d8449287
1 changed files with 22 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
Documentation/ch-checksumming.rst
View File

@ -1,32 +1,32 @@
Data and metadata are checksummed by default, the checksum is calculated before
write and verified after reading the blocks from devices. The whole metadata
block has a checksum stored inline in the b-tree node header, each data block
Data and metadata are checksummed by default. The checksum is calculated before
writing and verified after reading the blocks from devices. The whole metadata
block has an inline checksum stored in the b-tree node header. Each data block
has a detached checksum stored in the checksum tree.
There are several checksum algorithms supported. The default and backward
compatible is *crc32c*. Since kernel 5.5 there are three more with different
compatible algorithm is *crc32c*. Since kernel 5.5 there are three more with different
characteristics and trade-offs regarding speed and strength. The following list
may help you to decide which one to select.
CRC32C (32bit digest)
default, best backward compatibility, very fast, modern CPUs have
CRC32C (32 bits digest)
Default, best backward compatibility. Very fast, modern CPUs have
instruction-level support, not collision-resistant but still good error
detection capabilities
detection capabilities.
XXHASH (64bit digest)
can be used as CRC32C successor, very fast, optimized for modern CPUs utilizing
instruction pipelining, good collision resistance and error detection
XXHASH (64 bits digest)
Can be used as CRC32C successor. Very fast, optimized for modern CPUs utilizing
instruction pipelining, good collision resistance and error detection.
SHA256 (256bit digest)
a cryptographic-strength hash, relatively slow but with possible CPU
instruction acceleration or specialized hardware cards, FIPS certified and
in wide use
SHA256 (256 bits digest)
Cryptographic-strength hash. Relatively slow but with possible CPU
instruction acceleration or specialized hardware cards. FIPS certified and
in wide use.
BLAKE2b (256bit digest)
a cryptographic-strength hash, relatively fast with possible CPU acceleration
using SIMD extensions, not standardized but based on BLAKE which was a SHA3
finalist, in wide use, the algorithm used is BLAKE2b-256 that's optimized for
64bit platforms
BLAKE2b (256 bits digest)
Cryptographic-strength hash. Relatively fast, with possible CPU acceleration
using SIMD extensions. Not standardized but based on BLAKE which was a SHA3
finalist, in wide use. The algorithm used is BLAKE2b-256 that's optimized for
64-bit platforms.
The *digest size* affects overall size of data block checksums stored in the
filesystem. The metadata blocks have a fixed area up to 256 bits (32 bytes), so
@ -61,8 +61,8 @@ The accelerated versions are however provided by the modules and must be loaded
explicitly (:command:`modprobe sha256`) before mounting the filesystem to make use of
them. You can check in :file:`/sys/fs/btrfs/FSID/checksum` which one is used. If you
see *sha256-generic*, then you may want to unmount and mount the filesystem
again, changing that on a mounted filesystem is not possible.
Check the file :file:`/proc/crypto`, when the implementation is built-in, you'd find
again. Changing that on a mounted filesystem is not possible.
Check the file :file:`/proc/crypto`, when the implementation is built-in, you'd find:
.. code-block:: none
@ -72,7 +72,7 @@ Check the file :file:`/proc/crypto`, when the implementation is built-in, you'd
priority : 100
...
while accelerated implementation is e.g.
While accelerated implementation is e.g.:
.. code-block:: none