Bug 206835 - btrfs partitions with xxhash checksum fail to mount on ppc64
Summary: btrfs partitions with xxhash checksum fail to mount on ppc64
Status: RESOLVED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: btrfs (show other bugs)
Hardware: PPC-64 Linux
: P1 normal
Assignee: BTRFS virtual assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-12 21:50 UTC by Erhard F.
Modified: 2020-03-13 21:43 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.5.9
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (kernel 5.5.9, Talos II) (71.95 KB, text/plain)
2020-03-12 21:50 UTC, Erhard F.
Details
kernel .config (kernel 5.5.9, Talos II) (99.82 KB, text/plain)
2020-03-12 21:50 UTC, Erhard F.
Details

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.

Note You need to log in before you can comment on or make changes to this bug.