btrfs scrub error super=1 after clone-restore

[jowagner]

An empty btrfs filesystem is not restored fully, triggering an "super=1" error in a scrub run. (btrfs check, however, does not find anything wrong.)

Version tested: v0.3.11 (931b4a4), shipped with openSUSE Leap 15.3

Steps to reproduce:

#!/usr/bin/env bash

if [[ $(losetup list --all) ]] ; then
        echo "Conflicting loop devive"
        exit
fi

cd $(mktemp -d -p . issue-180-XXXX)

dd if=/dev/zero bs=1024k count=0 seek=8192 of=filesystem.img
losetup --find --show filesystem.img

mkfs.btrfs -m single /dev/loop0
#md5sum /dev/loop0

partclone.btrfs -c -s /dev/loop0 -o filesystem.pcl
losetup -d /dev/loop0
dd if=/dev/zero bs=1024k count=0 seek=8192 of=filesystem-new.img
losetup --find --show filesystem-new.img

partclone.btrfs -r -s filesystem.pcl -o /dev/loop0
#md5sum /dev/loop0
#btrfs check /dev/loop0
#md5sum /dev/loop0

mount /dev/loop0 /mnt
sleep 5
date
btrfs scrub start /mnt
sleep 75
date
btrfs scrub status /mnt

sleep 75

date
btrfs scrub start /mnt
sleep 75
date
btrfs scrub status /mnt

umount /mnt
losetup -d /dev/loop0

Observed output:

0+0 records in
0+0 records out
0 bytes copied, 3.1519e-05 s, 0.0 kB/s
/dev/loop0
btrfs-progs v4.19.1 
See http://btrfs.wiki.kernel.org for more information.

Label:              (null)
UUID:               61e44f23-b4e3-4a90-9974-d2dd6637920b
Node size:          16384
Sector size:        4096
Filesystem size:    8.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         single            8.00MiB
  System:           single            4.00MiB
SSD detected:       yes
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1     8.00GiB  /dev/loop0

Partclone v0.3.11 http://partclone.org
Starting to clone device (/dev/loop0) to image (filesystem.pcl)
Reading Super Block
Calculating bitmap... Please wait... 
done!
File system:  BTRFS
Device size:    8.6 GB = 524288 Blocks
Space in use: 131.1 KB = 8 Blocks
Free Space:     8.6 GB = 524280 Blocks
Block size:   16384 Byte
Elapsed: 00:00:02, Remaining: 00:00:00, Completed: 100.00%, Rate: 379.45MB/min, 
current block:        832, total block:     524288, Complete: 100.00%           
Total Time: 00:00:02, Ave. Rate:  379.5MB/min, 100.00% completed!
Syncing... OK!
Partclone successfully cloned the device (/dev/loop0) to the image (filesystem.pcl)
Cloned successfully.
0+0 records in
0+0 records out
0 bytes copied, 3.5556e-05 s, 0.0 kB/s
/dev/loop0
Partclone v0.3.11 http://partclone.org
Starting to restore image (filesystem.pcl) to device (/dev/loop0)
Calculating bitmap... Please wait...
done!
File system:  BTRFS
Device size:    8.6 GB = 524288 Blocks
Space in use: 131.1 KB = 8 Blocks
Free Space:     8.6 GB = 524280 Blocks
Block size:   16384 Byte
Elapsed: 00:00:02, Remaining: 00:00:00, Completed: 100.00%, Rate: 379.45MB/min, 
current block:        832, total block:     524288, Complete: 100.00%           
Total Time: 00:00:02, Ave. Rate:  379.5MB/min, 100.00% completed!
Syncing... OK!
Partclone successfully restored the image (filesystem.pcl) to the device (/dev/loop0)
Cloned successfully.
Tue  1 Mar 13:01:50 GMT 2022
scrub started on /mnt, fsid 61e44f23-b4e3-4a90-9974-d2dd6637920b (pid=16933)
Tue  1 Mar 13:03:05 GMT 2022
scrub status for 61e44f23-b4e3-4a90-9974-d2dd6637920b
        scrub started at Tue Mar  1 13:01:50 2022 and finished after 00:00:00
        total bytes scrubbed: 128.00KiB with 1 errors
        error details: super=1
        corrected errors: 0, uncorrectable errors: 0, unverified errors: 0
Tue  1 Mar 13:04:20 GMT 2022
scrub started on /mnt, fsid 61e44f23-b4e3-4a90-9974-d2dd6637920b (pid=16947)
Tue  1 Mar 13:05:36 GMT 2022
scrub status for 61e44f23-b4e3-4a90-9974-d2dd6637920b
        scrub started at Tue Mar  1 13:04:20 2022 and finished after 00:00:00
        total bytes scrubbed: 128.00KiB with 0 errors

Issue #176 suggests that some data written by mkfs.btrfs is not included.

Error message mentioned (but not explained) in
https://unix.stackexchange.com/questions/239765/how-to-fix-btrfs-superblock-error-after-resize-shrink-btrfs-couldnt-get-super

Related:

• Issue [btrfs] Unable to mount newly cloned filesystem #163

[jowagner]

With btrfs check version 5.16.1 (and partclone v0.3.18), the text "with 1 errors" is removed. super=1 is still reported but it is no longer clear that this is an error. The output format has changed considerably.

UUID:             60a28a9c-4572-4f4c-9ae5-66845bcea74a
Scrub started:    Tue Mar 15 16:24:01 2022
Status:           finished
Duration:         0:00:00
Total to scrub:   144.00KiB
Rate:             0.00B/s
Error summary:    super=1
  Corrected:      0
  Uncorrectable:  0
  Unverified:     0

dmsg still shows an error:

[ 9472.678108] BTRFS info (device loop0): scrub: started on devid 1
[ 9472.678150] BTRFS error (device loop0): bdev /dev/loop0 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[ 9472.678293] BTRFS info (device loop0): scrub: finished on devid 1 with status: 0

[jowagner]

According to https://btrfs.wiki.kernel.org/index.php/On-disk_Format#Superblock, there should be a copy of the superblock at 0x04000000. Looking at the domain map file produced with -D, this superblock copy is not recorded by partclone.btrfs as a used area (no + in the domain map file).

Checking a freshly created filesytstem, there is indeed data at this location:

$ tail -c +67108864 filesystem.img | hexdump -C | head
00000000  00 eb 5e 3e ae 00 00 00  00 00 00 00 00 00 00 00  |..^>............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 c3 22 a5 41 85 d6 41  41 a9 93 eb f8 55 a5 07  |..".A..AA....U..|
00000030  c8 00 00 00 04 00 00 00  00 01 00 00 00 00 00 00  |................|
00000040  00 5f 42 48 52 66 53 5f  4d 06 00 00 00 00 00 00  |._BHRfS_M.......|
00000050  00 00 00 50 00 00 00 00  00 00 40 10 00 00 00 00  |...P......@.....|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 02 00 00  00 00 40 02 00 00 00 00  |..........@.....|
00000080  00 06 00 00 00 00 00 00  00 01 00 00 00 00 00 00  |................|

The magic "_BHRfS_M" at 0x40 identifies this as a btrfs superblock and this seems to be a copy of the first superblock at 0x10000 (a different checksum at offset 0x0 and block location at offset 0x30 is expected):

$ tail -c +65536 filesystem.img | hexdump -C | head
00000000  00 4b 3f 16 60 00 00 00  00 00 00 00 00 00 00 00  |.K?.`...........|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 c3 22 a5 41 85 d6 41  41 a9 93 eb f8 55 a5 07  |..".A..AA....U..|
00000030  c8 00 00 01 00 00 00 00  00 01 00 00 00 00 00 00  |................|
00000040  00 5f 42 48 52 66 53 5f  4d 06 00 00 00 00 00 00  |._BHRfS_M.......|
00000050  00 00 00 50 00 00 00 00  00 00 40 10 00 00 00 00  |...P......@.....|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 02 00 00  00 00 40 02 00 00 00 00  |..........@.....|
00000080  00 06 00 00 00 00 00 00  00 01 00 00 00 00 00 00  |................|
00000090  00 00 10 00 00 00 40 00  00 00 40 00 00 00 10 00  |......@...@.....|

It seems that partclone.btrfs misses this superblock copy.

Note that larger filesystems have a 3rd copy at 0x4000000000 (256 GiB in) according to the above link.

[Thomas-Tsai]

oh yes, We should add to btrfs check.

thank you.

[Thomas-Tsai]

Hi,
We released the new partclone 0.3.19 for this update and upgraded BTRFS support to 0.5.11.

Please kindly give it a try later.

Thank you.