Created attachment 287899 [details] dmesg (kernel 5.5.9, Talos II) # mkfs.btrfs -L ppc64_exp -f --csum xxhash /dev/nvme0n1p7 btrfs-progs v5.4.1 See http://btrfs.wiki.kernel.org for more information. Detected a SSD, turning off metadata duplication. Mkfs with -m dup if you want to force metadata duplication. Label: ppc64_exp UUID: f66e91b3-e89b-4b47-a64b-8ade8d02306d Node size: 16384 Sector size: 4096 Filesystem size: 80.00GiB Block group profiles: Data: single 8.00MiB Metadata: single 8.00MiB System: single 4.00MiB SSD detected: yes Incompat features: extref, skinny-metadata Checksum: xxhash64 Number of devices: 1 Devices: ID SIZE PATH 1 80.00GiB /dev/nvme0n1p7 # mount /dev/nvme0n1p7 /mnt/mychroot/ mount: /mnt/mychroot: wrong fs type, bad option, bad superblock on /dev/nvme0n1p7, missing codepage or helper program, or other error. Kernel dmesg shows: [...] [ 2836.707685] BTRFS error (device nvme0n1p7): superblock checksum mismatch [ 2836.727300] BTRFS error (device nvme0n1p7): open_ctree failed
Created attachment 287901 [details] kernel .config (kernel 5.5.9, Talos II)
DOes this happen with the other hashes, like sha256?
No, does not happen with crc32, sha256 and blake2b. These can be cleanly mounted and unmounted after formatting.
So this looks like a difference in implementation of the userspace and kernel of xxhash. Can you please try this patch to btrfs-progs: --- a/crypto/hash.c +++ b/crypto/hash.c @@ -23,6 +23,7 @@ int hash_xxhash(const u8 *buf, size_t length, u8 *out) * NOTE: we're not taking the canonical form here but the plain hash to * be compatible with the kernel implementation! */ + hash = bswap_64(hash); memcpy(out, &hash, 8); return 0; --- It switches the endianity. This naturally does not work on intel but on a big endian machine this might be the missing step.
Yep, this works! Though somehow the patch did not apply to btrfs-progs v5.4.1. Had to edit crypto/hash.c manually.
Great, thanks for testing, proper fix will be in the next release.