Bug 206835

Summary: btrfs partitions with xxhash checksum fail to mount on ppc64
Product: File System Reporter: Erhard F. (erhard_f)
Component: btrfsAssignee: BTRFS virtual assignee (fs_btrfs)
Status: RESOLVED CODE_FIX    
Severity: normal CC: dsterba
Priority: P1    
Hardware: PPC-64   
OS: Linux   
Kernel Version: 5.5.9 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg (kernel 5.5.9, Talos II)
kernel .config (kernel 5.5.9, Talos II)

Description Erhard F. 2020-03-12 21:50:09 UTC 
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
Comment 1 Erhard F. 2020-03-12 21:50:54 UTC 
Created attachment 287901 [details]
kernel .config (kernel 5.5.9, Talos II)
Comment 2 David Sterba 2020-03-13 00:09:02 UTC 
DOes this happen with the other hashes, like sha256?
Comment 3 Erhard F. 2020-03-13 00:29:10 UTC 
No, does not happen with crc32, sha256 and blake2b. These can be cleanly mounted and unmounted after formatting.
Comment 4 David Sterba 2020-03-13 01:01:05 UTC 
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.
Comment 5 Erhard F. 2020-03-13 01:32:40 UTC 
Yep, this works!

Though somehow the patch did not apply to btrfs-progs v5.4.1. Had to edit crypto/hash.c manually.
Comment 6 David Sterba 2020-03-13 21:43:47 UTC 
Great, thanks for testing, proper fix will be in the next release.