How to repair "btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1"?

[HIRAKI Hideaki <hhiraki@nig.ac.jp>]

Hello,

I have two questions and a bug report.

Once upon a time I converted an ext3 partition to BTRFS to mount on
/var/lib/docker and was happy with it. Recently an error occured:

 kernel: BTRFS info (device sdc1): leaf 2013170442240 total ptrs 171 free space 6365
 kernel: BTRFS error (device sdc1): eb 2013170442240 invalid extent inline ref type 182
 kernel: BTRFS: Transaction aborted (error -22)
 kernel: BTRFS: error (device sdc1) in btrfs_run_delayed_refs:3089: errno=-22 unknown
 kernel: BTRFS info (device sdc1): forced readonly
 kernel: BTRFS error (device sdc1): pending csums is 77824

Now I know this was caused by the kernel upgrade from 4.12.5 to 4.14.83 which
introduced an additional check of alignments rather than by a recent trivial
file system corruption. But I was hasty and commited such follies as hard
resets on busy kernel, btrfs rescue chunk-recover -y, btrfs check --repair,
etc. As you may expect, the partition is not mountable any more:

# mount -o compress=lzo,noatime /dev/sdc1 /mnt/temp
mount: /mnt/temp: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.

 kernel: BTRFS info (device sdc1): use lzo compression
 kernel: BTRFS info (device sdc1): disk space caching is enabled
 kernel: BTRFS info (device sdc1): has skinny extents
 kernel: BTRFS info (device sdc1): bdev /dev/sdc1 errs: wr 1396, rd 0, flush 0, corrupt 0, gen 0
 kernel: BTRFS error (device sdc1): logical 3955568533504 len 1073741824 found bg but no related chunk
 kernel: BTRFS error (device sdc1): failed to read block groups: -2
 kernel: BTRFS error (device sdc1): open_ctree failed

Even btrfs check aborts:

# btrfs check --repair /dev/sdc1
enabling repair mode
Opening filesystem to check...
volumes.c:1729: btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1
btrfs(+0x2e246)[0x562a5547c246]
btrfs(+0x30cac)[0x562a5547ecac]
btrfs(btrfs_read_block_groups+0x27d)[0x562a55471f8d]
btrfs(btrfs_setup_all_roots+0x35f)[0x562a5546bc9f]
btrfs(+0x1e0cb)[0x562a5546c0cb]
btrfs(open_ctree_fs_info+0x8c)[0x562a5546c2cc]
btrfs(cmd_check+0x4db)[0x562a554b670b]
btrfs(main+0x7a)[0x562a55461e2a]
/lib64/libc.so.6(__libc_start_main+0xee)[0x7f83e3598bde]
btrfs(_start+0x2a)[0x562a55461f3a]
Aborted

How to repair this file system?


The second question is about btrfs-restore. It doesn't restore subvolumes
even when the destination path is in a BTRFS file system. "btrfs restore -l"
is to list subvolumes but the output lacks the path (relative to the top
level subvolume) information. With the information, the destination of
btrfs-restore with the subvolumes could be prepared and hopefully
"dockerd" would work properly with the restored file tree, though the files
would be duplicated significantly.

How can the subvolumes' paths be obtained from an unmountable file system?


By the way, some constants in the source code had to be increased to run
btrfs-restore for me.

--- cmds-restore.c~   2018-11-03 19:06:34.000000000 +0900
+++ cmds-restore.c    2019-01-09 00:34:17.000000000 +0900
@@ -289,7 +289,7 @@ static int copy_one_inline(struct btrfs_
 {
        struct extent_buffer *leaf = path->nodes[0];
        struct btrfs_file_extent_item *fi;
-       char buf[4096];
+       char buf[65536];
        char *outbuf;
        u64 ram_size;
        ssize_t done;
@@ -729,7 +729,7 @@ static int copy_file(struct btrfs_root *
        }
 
        while (1) {
-               if (loops >= 0 && loops++ >= 1024) {
+               if (loops >= 0 && loops++ >= 102400) {
                        enum loop_response resp;
 
                        resp = ask_to_continue(file);
@@ -1007,7 +1007,7 @@ static int search_dir(struct btrfs_root
        }
 
        while (leaf) {
-               if (loops++ >= 1024) {
+               if (loops++ >= 102400) {
                        printf("We have looped trying to restore files in %s "
                               "too many times to be making progress, "
                               "stopping\n", in_dir);

The first one is to avoid the abortion with "*** stack smashing detected ***".
So, not only the increase but also a size checking code (at least) is
necessary to fix this bug. I hope the other two constants (if necessary) will
be tunable from the command line option.


For your information:

# uname -a
Linux plcd1 4.14.83-gentoo #1 SMP Wed Dec 19 00:20:46 JST 2018 x86_64 Intel(R) Core(TM) i7-3970X CPU @ 3.50GHz GenuineIntel GNU/Linux

# btrfs --version
btrfs-progs v4.19 

# btrfs fi show
Label: none  uuid: 5e3d788d-5b81-4e3e-8776-5a131d008cbc
        Total devices 1 FS bytes used 1.41TiB
        devid    1 size 1.82TiB used 1.43TiB path /dev/sdc1


Regards,

Hideaki