[Btrfs-devel] Is crc32 adequate to detect real-life data corruption in filesystem's blocks?

Chris Mason chris.mason at oracle.com
Wed Jan 9 03:01:46 PST 2008

On Wed, 9 Jan 2008 10:33:04 +0600
sftf <sftf-misc at mail.ru> wrote:

> >> What about multiple errors detection with crc32?
> >> Is it work?
> CM> This will depend on who you ask.  Over the long term, btrfs will
> CM> support a number of stronger checksums for metadata and data.
> CM> There are 256 bits reserved in the metadata blocks, and the file
> CM> data checksums don't require a fixed size, so it will be possible
> CM> to have different sized checksums on different files.
> Are checksums is per device block or per extent or per file?

There is a checksum stored inside a header for every btree block.  The
file data checksums are stored in the btree (outside of the file
block).  Right now the file data checksums are stored for every 4k.

> CM> In practice, 32 bit crcs are a good tradeoff between performance
> CM> and safety.  Some people will surely want better, and we'll
> CM> examine other algorithms as the FS matures.
> And what if the (block with) checksums will be corrupted but not data
> itself?

Since the data checksums are stored in the metadata btree, this is the
same problem of metadata corruption in general. The long term plan is to
solve it with mirroring the btree blocks.


More information about the Btrfs-devel mailing list