BTRFS and 6.14 kernels

[BlueGoliath]

Hi,

I'm not sure if this is the place to ask but what is the advisable way to update here? How do you check what checksum is being used? How do you change it?

Please see this issue: https://bbs.archlinux.org/viewtopic.php?id=304822 for context.

[Forza-tng]

You can use btrfs inspect-internal dump-super to check current csum type:

btrfs inspect-internal dump-super /dev/sdb1 |grep csum_type
csum_type               0 (crc32c)

If you can mount the filesystem, the current csum will be printed to dmesg:

# dmesg
[   17.068367] [ T3840] BTRFS info (device dm-26): first mount of filesystem fe0a1142-51ab-4181-b635-adbf9f4ea6e6
[   17.068393] [ T3840] BTRFS info (device dm-26): using crc32c (crc32c-intel) checksum algorithm

It is possible as an experimental feature to change csum type using btrfstune --csum. It requires a version of btrfs-progs that has experimental features enabled.

• https://wiki.tnonline.net/w/Btrfs/Checksum_Algorithms
• https://wiki.tnonline.net/w/Btrfs/Statically_built_btrfs-progs

[BlueGoliath]

I think it would be best to not mess with experimental features if possible.

I know I'm probably barking up the wrong tree, but what kernel modules, if any, are needed now? Currently I have:

crc32 libcrc32c crc32c_generic crc32c-intel crc32-pclmul

[BlueGoliath]

Just to add, I am using crc32c-intel apparently.

[kdave]

Module dependencies can be found in the output of modinfo btrfs, there are softdeps which are modules that get loaded by modprobe/insmod but the functionality may not be used. Then there are hard dependencies that resolve symbols from the modules at load time.

softdep:        pre: blake2b-256
softdep:        pre: sha256
softdep:        pre: xxhash64
softdep:        pre: crc32c
...
depends:        xor,raid6_pq

For crc32c there's some magic to load the accelerated module so it does not appear in the list.

[SkyKwas]

There's a few ways to check what what checksum Btrfs is using:

• Run cat /sys/fs/btrfs/*/checksum (see man 5 btrfs)
  This will give an output like crc32c (crc32c-x86), where the first field (crc32c) is the name of the algorithm and the second field ((crc32c-x86)) is the name of the implementation (software or hardware accelerated). Before 6.14, the name of the hardware implementation (the accelerated/faster version) was called "crc32c-intel"; since 6.14, it's now called "crc32c-x86"; the software implementation, "crc32c-generic", stayed the same.
  --
  The confusion comes from the module names. Before 6.14, the software implementation was called "crc32c_generic" and the hardware implementation was called "crc32c_intel". Since 6.14, the hardware implementation is now "built-in" as part of the algorithm if CONFIG_CRC_OPTIMIZATIONS is enabled. The module "crc32c_intel" doesn't exist anymore, there is only "crc32c_generic". The CONFIG option determines if "crc32c_generic" contains the hardware accelerated versions.
  --
  If you run a custom kernel, ensure CONFIG_CRC_OPTIMIZATIONS=y and recompile the kernel, do your distribution-specific things to have it ready to boot, and reboot. After the machine is rebooted, run cat /sys/fs/btrfs/*/checksum again and it should give a result of crc32c (crc32c-x86); if it doesn't, then the "btrfs" module got loaded before the "crc32c_generic" module. To fix this, you'll need to have Btrfs and the CRC32c kernel options built-in (<*>) and not as a moduel (<M>) OR have an initramfs with the required modules including "btrfs" and "crc32c_generic" or whatever algorithm you choose for Btrfs.
  --
  As an example, I use Dracut to make my initramfs and use the following line in /etc/dracut.conf.d/my_dracut.conf:
  drivers+=" <other kernel modules> btrfs crc32c_generic "
  If you want to use SHA256:
  drivers+=" <other kernel modules> btrfs sha256_ssse3 "

• Run dmesg | grep -E 'BTRFS.*checksum'
  This will give an output like:
  [ 1.234] [ T1234] BTRFS info (device sda1): using crc32c (crc32c-x86) checksum algorithm

[ebiggers]

Doesn't it "just work" now because btrfs.ko has a softdep on "crc32c" which is one of the aliases of "crc32c_generic.ko"? FWIW "crc32c_generic.ko" is going to be renamed to "crc32c.ko" in 6.16, but it should not matter, since there should be no need to explicitly list it anymore --- it should get included in the initramfs automatically via the softdep. (I guess people got in the habit of explicitly listing "crc32c-intel.ko", so they feel like they should still be listing something. But it is not needed anymore.)

[ebiggers]

(But for SHA-256 you still need to explicitly list sha256_ssse3.ko. I will be fixing that next...)

[SkyKwas]

Doesn't it "just work" now because btrfs.ko has a softdep on "crc32c" which is one of the aliases of "crc32c_generic.ko"? FWIW "crc32c_generic.ko" is going to be renamed to "crc32c.ko" in 6.16, but it should not matter, since there should be no need to explicitly list it anymore --- it should get included in the initramfs automatically via the softdep. (I guess people got in the habit of explicitly listing "crc32c-intel.ko", so they feel like they should still be listing something. But it is not needed anymore.)

No, it doesn't "just work" -- you do, in fact, need to add "crc32c_generic" to the list of modules included in the initramfs. When 6.14 dropped, I spent several hours experimenting different kernel options and included modules to figure out what I really needed.

If you don't include "crc32c_generic" in the initramfs, then Btrfs will use the software implementation, not the hardware one. I noticed this because my root partition loaded with crc32c (crc32c-generic) and my boot partition loaded with crc32c (crc32c-x86) when I didn't include the module; when I did include the module, they both loaded with crc32c (crc32c-x86).

I can't do a quick test right now with CRC32c because I'm using SHA256, but I can tell you that the same thing happens with SHA256: root loads with sha256 (sha256-generic) and boot loads with sha256 (sha256-avx2) -- I just verified this as I'm writing this.

Tools like Dracut seem to only pull in dependencies if they are a hard dependency. Btrfs has the checksum algorithms as a soft dependency -- as in, they are not required for Btrfs to function. We can verify this with lsmod.

When I don't include "sha256_ssse3", lsmod prints the following:
Module Size Used by
...
sha256_ssse3 36864 1
...
btrfs 2490368 2
...

Notice how sha256_ssse3 gets loaded AFTER btrfs? That's because all kernel modules are located on root, which the initramfs can't access until it mounts the filesystem. So, the btrfs module gets loaded first because the initramfs needs to mount to filesystem. Then, the initramfs gets ready to mount the boot partition, but before it does, it notices that one of btrfs's soft dependencies is now available (sha256_ssse3); so the initramfs loads sha256_ssse3 and then mounts the boot partition. If you want more debugging information, check dmesg, it will tell you the same story.

Also notice in the lsmod output that there are no listed "Used by" modules, meaning that it really is just a soft dependency. If it were a hard dependency (and thus Dracut would pull it in automatically), we would see:
Module Size Used by
...
btrfs 2490368 2
...
sha256_ssse3 36864 3 btrfs
...


When I do include "sha256_ssse3", lsmod prints the following:
Module Size Used by
...
btrfs 2490368 2
...
sha256_ssse3 36864 3
...


[ebiggers]

If you don't include "crc32c_generic" in the initramfs, then Btrfs will use the software implementation, not the hardware one.

I don't think this is plausible, as the same module provides the crypto API support for both the generic and arch-optimized algorithms now.

[ebiggers]

But again, I'm just talking about crc32c. sha256 is still broken.

[BlueGoliath]

So I decided to bite the bullet after reading comments here and remove what was being complained about using mkinitcpio and nothing seems broken that wasn't before.

But from reading this conversation it's clear the whole module dependency hierarchy conveying and naming of this stuff is a giant cr*p show and should probably be done better. Also, why not just ignore the modules instead of throwing an error?

[ebiggers]

Yes, for 6.14 and later kernels just remove crc32c-intel.ko from your initramfs if you had added it to there at some point. It is not needed anymore. Also see https://www.reddit.com/r/linux_gaming/comments/1jvqtyn/no_arch_linux_kernel_builds_are_not_broken/.

[BlueGoliath]

See what? It doesn't take me anywhere.

And if it's no longer possible to build initramfs as you could before because of kernel changes, yes, it is broken.

Edit: I have that person blocked. Of course the schizo moderators let that up instead of letting any corrections be made in the comments of the post that I made.

[BlueGoliath]

While i'm at it, I'm just going to point out that, you're suggesting only "crc32c-intel" be removed when in fact it's three modules that needed to be removed.

So just to recap:

1. I clearly asked to change the checksum because I thought the algorithm being used would not work anymore and I wouldn't be able to boot. Instead of making it clear that wasn't the case and ending it there, I got suggestions on how to check and change the checksum algorithm using a "experimental" features, something no user should have to mess with.

2. Not even knowledgeable people here are entirely aware of the code dependency and what's actually needed.

3. I've been told now by a contributor to do something that would still result in a broken system.

4. It still isn't clear what the difference is between "crc32" and "crc32c_generic" because the names are absolutely terrible. More so before, with the other two, WTF is "libcrc32"???

5. This is going to happen again in the future because for some reason it couldn't be done all at the same time.

6. There will likely be no news coverage of this anywhere and people aren't going to know what to remove now or in the future.

This is complete and utter madness that, if done by Microsoft, would result in a PR crap storm of epic proportions, but in Linux land this kind of thing is just par for the course. No one bats and eye and anyone who questions it gets labeled a troll.

[BlueGoliath]

Oh, and just to add since I somehow didn't think of it:

btrfs inspect-internal dump-super /dev/sdb1 |grep csum_type

Returned crc32c-intel which made it sound like crc32c-intel is required. It now lists just crc32c but how exactly is ANYONE supposed to know that's the kernel module being used and isn't a hard dependency?

[ebiggers]

I clearly asked to change the checksum

Right, which is why someone answered that question.

If you have a different problem that you're trying to solve, you should clearly explain that problem.

It sounds like the actual problem that you're trying to solve is that you're getting an initramfs build error due to "crc32c-intel" no longer existing. Again, the solution is to just remove that module. There's no need to manually add accelerated CRC modules to the initramfs anymore.

Out of curiosity, which Linux distro are you using, and do you know how crc32c-intel got into your list of initramfs modules in the first place?

[kdave]

btrfs inspect-internal dump-super /dev/sdb1 |grep csum_type

Returned crc32c-intel which made it sound like crc32c-intel is required. It now lists just crc32c

The command inspect-internal always shows just the algorithm name, so it was always crc32c (btrfs_print_superblock -> btrfs_super_csum_name -> btrfs_csums[csum_type].name). The implementation is loaded at run time and exported to /sys/fs/btrfs/*/checksum, so there it would be someting like crc32c (crc32c-intel)