1. Please describe the problem: On a SSE4.2 capable system, btrfs should use crc32c-intel, not crc32c-generic. 2. What is the Version-Release number of the kernel: Linux version 5.8.4-200.fc32.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1), GNU ld version 2.34-4.fc32) #1 SMP Wed Aug 26 22:28:08 UTC 2020 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : This is the first version I noticed btrfs is loaded. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: $ dmesg -t | grep crc32 Btrfs loaded, crc32c=crc32c-generic 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: 6. Are you running any modules that not shipped with directly Fedora's kernel?: No. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. -- No entries --
Probably CONFIG_CRYPTO_CRC32C_INTEL=m should be changed to =y because: CONFIG_BTRFS_FS=y
I have the same issue on Ryzen 3300X and Fedora 33. But it works previously on old AMD CPU in Fedora 32 so not sure when this bug striked. $ lscpu | grep sse4_2 SSE 4.2 available. $ dmesg | grep crc32c [ 0.631456] Btrfs loaded, crc32c=crc32c-generic Users also reporting the same issue on 'Intel(R) Core(TM) i7-1065G7'. Users nuking their fresh f33 installations because of this bug and complain. That's sort of urgent bug.
Josef, Justin, would switching CONFIG_CRYPTO_CRC32C_INTEL to 'y' actually resolve this issue? I'm somewhat skeptical myself...
cat /sys/fs/btrfs/$(blkid info -o value -s UUID $DEVICE)/checksum will tell you which crc we're currently using. We just spit out whatever crypto library is currently loaded at the time, and since it can change this can be completely different later on. If the above command doesn't spit out crc32c-intel then it still doesn't really change, because again btrfs is just calling into the crypto library, so it can change arbitrarily while the file system is loaded. If you want to change the printk then by all means switch it to =Y, but it makes no difference practically speaking.
Also, why exactly are users nuking an entire install because of the wrong crc mechanism? We didn't have built in crc32c for a while, and while it's certainly slower, it's not mind numbingly slow, this is how it worked before and thus we have a lot of async stuff built in to make it as fast as possible. It seems like a bit of an overreaction without first getting some clarity.
(In reply to Josef Bacik from comment #5) Josef, i've answered here https://pagure.io/fedora-btrfs/project/issue/34#comment-699687 and i can't answer for those who nuked their fresh fedora 33. Thanks for explanation and sorry for noise. Probably need to document somehow this since Arch Wiki [1] for example still contain outdated information and other people could misinformed. [1]: https://wiki.archlinux.org/index.php/Btrfs#Checksum_hardware_acceleration
I think at this point, we can safely judge this to not be a real bug.