Talk:Bcachefs

Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:

A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 17:22, 5 April 2025 (UTC)
:: Your reply ~~~~

Update note in "Kernel" section

Talk status

This discussion is still ongoing as of 2025-03-31.

The following Note box is outdated for kernel versions >=6.14.0:

Note
If the crc32c-intel module is available and bcachefs loads before it (or is built in) the CRC32 hardware instruction will not be used resulting in increased system resource utilisation. Ensure that the module loads before bcachefs or build it into the kernel to avoid this.

It's no longer called crc32c-intel, it now depends on the architecture as far as I know; on x86_64 systems, it's crc32c-x86.

I was going to update the above note box to look like the one in the Btrfs wiki page after some changes (Btrfs -> Bcachefs):

Proposed changes - Please make edits here until a final revision is agreed upon.

Update the following note box from Btrfs to Bcachefs so that it applies to this wiki page:

Note
Btrfs uses checksum algorithms; if there is no hardware acceleration, then it will use the generic software implementation resulting in increased system resource utilization.

man 5 btrfs states that we can check if Btrfs is using an accelerated version via:

user $cat /sys/fs/btrfs/<UUID of partition formatted with btrfs>/checksum

crc32c (crc32c-generic)

If the result is (*-generic), Btrfs is using the generic software implementation; this could be because the btrfs kernel module gets loaded before the related checksum kernel module. To fix this, ensure that the checksum module is loaded before btrfs; this can be done via:

- Making the checksum module built-in (<*> instead of <M>).

- Adding the module to an initramfs (this can be done automatically with Dracut).

Once we've made our changes, we can check again:

user $cat /sys/fs/btrfs/<UUID of partition formatted with btrfs>/checksum

crc32c (crc32c-x86)

The result might vary, but the important part is that it does *NOT* say (*-generic)!

The problem is that I cannot find a way to check if Bcachefs is using the hardware accelerated checksum like how Btrfs does.

For example, as stated in the Btrfs note, I can simply run:

user $cat /sys/fs/btrfs/<UUID of partition formatted with btrfs>/checksum

crc32c (crc32c-generic)

And the output tells us that Btrfs is using the CRC32c checksum (crc32c) and it's using the software implementation ((crc32c-generic)).

For Bcachefs, the only files I'm able to find are:

• /sys/fs/bcachefs/<UUID of partition formatted with bcachefs>/options/data_checksum
• /sys/fs/bcachefs/<UUID of partition formatted with bcachefs>/options/metadata_checksum

Both of which give us a result looking like:

none [crc32c] crc64 xxhash

This output tells us that Bcachefs is using the CRC32c checksum ([crc32c]), but it doesn't tell us if it's the software or hardware implementation.

I haven't played with Bcachefs that much, I was just hoping to find a quick solution.

FlyingBullets (talk) 23:52, 31 March 2025 (UTC)

Are you sure that it's just been renamed crc32c-intel?

/usr/src/linux-6.13.3-gentoo-r1 $grep -rsin 'crc32c-intel' | wc -l

6

/usr/src/linux-6.13.3-gentoo-r1 $grep -rsin 'crc32c-x86' | wc -l

0

/usr/src/linux-6.14.0-gentoo $grep -rsin 'crc32c-intel' | wc -l

0

/usr/src/linux-6.14.0-gentoo $grep -rsin 'crc32c-x86' | wc -l

0

It looks like there was a major refactor between 6.13 and 6.14 (this commit? https://github.com/torvalds/linux/commit/55d1ecceb8d6a5c9ceff7c6528075bd0ce4e8366) where it was completely rewired. It might just be enabled by the arch now, automagically?

As for checking which is in use, I don't know. It doesn't look like bcachefs exposes anything useful. I suggest putting in a request/issue over on the GitHub (https://github.com/koverstreet/bcachefs-tools), though this may also require additional FS-level work (not your problem).

The quick and easy solution that you want is building both into the kernel; this is only an issue if bcachefs is built-in and crc32c-intel (or the new equivalent - I couldn't see it at a glance) is not, or if both are modules.

—Kangie (talk) 00:47, 1 April 2025 (UTC)

>Are you sure that it's just been renamed crc32c-intel?

Yes, running cat on the checksum file on kernel 6.14.0 returns (crc32c-x86).

>The quick and easy solution that you want is building both into the kernel...

It can still work with both being modules, it just depends on (from what I found originally from previous editors) which is loaded first. When using Btrfs on kernels <6.14.0, I had CONFIG_BTRFS_FS=m and CONFIG_CRYPTO_CRC32C_INTEL=m; and Btrfs used the hardware accelerated version. For kernel versions >=6.14.0, the rewrite changed the CRC optimizations to be built-in via CONFIG_CRC_OPTIMIZATIONS=y. Sooooo... I guess we don't have to worry about Bcachefs not using the hardware accelerated versions... because they're built-in?

The original issue still remains though, where there is no way to know if Bcachefs is using the hardware accelerated versions. I'll take your word on filing an issue on GitHub about this.

Also, as a personal question to improve my skill, how were you able to find the commit so fast?

FlyingBullets (talk) 14:55, 1 April 2025 (UTC)