convert/source-fs.c:277: record_file_blocks: BUG_ON cur_off - key.offset >= extent_num_bytes triggered, value 1

[cmurf]

User reports a BUG_ON when converting an ext4 file system. https://bugzilla.redhat.com/show_bug.cgi?id=2101045

btrfs-progs-5.18-1.fc36.x86_64
e2fsprogs-1.46.5-2.fc36.x86_64
kernel 5.18.5-200.fc36.x86_64

# e2fsck -f -v -y /dev/mapper/vg_backup-lv_backup
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

    12266588 inodes used (1.34%, out of 915660800)
       37031 non-contiguous files (0.3%)
       17584 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 12083505/16214/69
  3107368091 blocks used (42.42%, out of 7325267968)
           0 bad blocks
        1391 large files

     4370504 regular files
     7679524 directories
          13 character device files
           0 block device files
          62 fifos
    69886733 links
      216349 symbolic links (166590 fast symbolic links)
         127 sockets
------------
    82153312 files
# btrfs-convert -L /dev/mapper/vg_backup-lv_backup
btrfs-convert from btrfs-progs v5.18

Source filesystem:
  Type:           ext2
  Label:          backup
  Blocksize:      4096
  UUID:           8407aaf9-3225-4b7d-b6fd-af75e97822c7
Target filesystem:
  Label:
  Blocksize:      4096
  Nodesize:       16384
  UUID:           b0054b66-d06b-458d-b6dd-74dd4d2d5e78
  Checksum:       crc32c
  Features:       extref, skinny-metadata, no-holes (default)
    Data csum:    yes
    Inline data:  yes
    Copy xattr:   yes
Reported stats:
  Total space:    12412111552512
  Free space:     16709885534208 (134.63%)
  Inode count:       915660800
  Free inodes:       903394212
  Block count:      3030300672
Create initial btrfs filesystem
Create ext2 image file
Create btrfs metadata
convert/source-fs.c:277: record_file_blocks: BUG_ON `cur_off - key.offset >= extent_num_bytes` triggered, value 1
btrfs-convert(record_file_blocks+0x3ff)[0x5596fd4115df]
btrfs-convert(block_iterate_proc+0xc2)[0x5596fd4116e2]
btrfs-convert(+0x158b8)[0x5596fd4118b8]
/lib64/libext2fs.so.2(+0x13c8f)[0x7fba3169ac8f]
/lib64/libext2fs.so.2(+0x1f743)[0x7fba316a6743]
/lib64/libext2fs.so.2(ext2fs_block_iterate2+0x30)[0x7fba316a6b70]
btrfs-convert(+0x1595b)[0x5596fd41195b]
btrfs-convert(+0x16877)[0x5596fd412877]
btrfs-convert(+0x181ae)[0x5596fd4141ae]
btrfs-convert(main+0x477)[0x5596fd40a937]
/lib64/libc.so.6(+0x29550)[0x7fba31439550]
/lib64/libc.so.6(__libc_start_main+0x89)[0x7fba31439609]
btrfs-convert(_start+0x25)[0x5596fd40aa65]
Aborted (core dumped)

This user also runs into #487 but I can't tell if that's related to this issue. When I tried converting an empty 28T ext4, I did run into that issue, but could not reproduce the crash.

[mike1703]

I seem to run into the same issue on an Debian bullseye.

I noticed in the free space report that the free space is 1663.23% which is obviously wrong.

btrfs-progs 5.10.1-2
e2fsprogs 1.46.2-2
Linux 5.10.0-19

# e2fsck -f -v -y /dev/mapper/customname
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity                                        
Pass 4: Checking reference counts                                              
Pass 5: Checking group summary information                                     
                                                                               
     1850247 inodes used (0.34%, out of 549404672)
       12397 non-contiguous files (0.7%)
        1116 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 1838728/6085/1
  2641255696 blocks used (60.09%, out of 4395237376)
           0 bad blocks
         792 large files

     1182393 regular files
      662221 directories
           8 character device files
           1 block device file
           0 fifos
     3567927 links
        5554 symbolic links (5355 fast symbolic links)
          61 sockets
------------
     5418165 files
# btrfs-convert -L /dev/mapper/customname
create btrfs filesystem:
        blocksize: 4096
        nodesize:  16384
        features:  extref, skinny-metadata (default)
        checksum:  crc32c
free space report:
        total:     410706247680
        free:      6830975287296 (1663.23%)
creating ext2 image file
creating btrfs metadata
convert/source-fs.c:277: record_file_blocks: BUG_ON `cur_off - key.offset >= extent_num_bytes` triggered, value 1
btrfs-convert(+0x10635)[0x564ea26c5635]
btrfs-convert(record_file_blocks+0x1cb)[0x564ea26c5a9c]
btrfs-convert(block_iterate_proc+0xb7)[0x564ea26c5bee]
btrfs-convert(+0x10f2a)[0x564ea26c5f2a]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x1943b)[0x7f46bdb7543b]
/lib/x86_64-linux-gnu/libext2fs.so.2(+0x1a210)[0x7f46bdb76210]
/lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_block_iterate2+0x2c)[0x7f46bdb766dc]
btrfs-convert(+0x10d69)[0x564ea26c5d69]
btrfs-convert(+0x11c36)[0x564ea26c6c36]
btrfs-convert(main+0x1b54)[0x564ea26c3514]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f46bd8c9d0a]
btrfs-convert(_start+0x2a)[0x564ea26c38da]
Aborted

[mike1703]

It might or might not be relevant, but I want to add that this is an older ext4 which was created without the 64bit feature initially which was then added when I added an additional disk to the RAID5 so I could grow the ext4 to the full size.

output from dumpe2fs
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

[mike1703]

I'm probably affected by something old. Using 6.0.2 it seems to run much longer without failure yet.
Looking at the changelog there might be a relevant change in btrfs-progs-5.19 (2022-08-16)

• convert: support large filesystems (block count > 32bit)