Re: "missing data block" when converting ext4 to btrfs

[Christian Zangl <coralllama@gmail.com>]

On 2020-07-14 10:09, Qu Wenruo wrote:
> 
> 
> On 2020/7/14 下午3:58, Christian Zangl wrote:
>> On 2020-07-14 08:10, Qu Wenruo wrote:
>>>
>>>
>>> On 2020/7/14 上午3:46, Christian Zangl wrote:
>>>> I am on a test VM where I am trying to convert a second disk to btrfs.
>>>>
>>>> The conversion fails with the error missing data block for bytenr
>>>> 1048576 (see below).
>>>>
>>>> I couldn't find any information about the error. What can I do to fix
>>>> this?
>>>>
>>>> $ fsck -f /dev/sdb1
>>>> fsck from util-linux 2.35.2
>>>> e2fsck 1.45.6 (20-Mar-2020)
>>>> 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
>>>> /dev/sdb1: 150510/4194304 files (0.5% non-contiguous), 2726652/16777216
>>>> blocks
>>>>
>>>> $ btrfs-convert /dev/sdb1
>>>> create btrfs filesystem:
>>>>           blocksize: 4096
>>>>           nodesize:  16384
>>>>           features:  extref, skinny-metadata (default)
>>>>           checksum:  crc32c
>>>> creating ext2 image file
>>>> ERROR: missing data block for bytenr 1048576
>>>> ERROR: failed to create ext2_saved/image: -2
>>>> WARNING: an error occurred during conversion, filesystem is partially
>>>> created but not finalized and not mountable
>>>
>>> Can btrfs-convert -r rollback the fs?
>>
>> No:
>>
>> $ sudo btrfs-convert -r /dev/sdb1
>> No valid Btrfs found on /dev/sdb1
>> ERROR: unable to open ctree
>> ERROR: rollback failed
>>
>> If I do `fsck -f /dev/sdb1` I get lots of errors:
>>
>> t-arch:~$ sudo fsck -f /dev/sdb1
>> fsck from util-linux 2.35.2
>> e2fsck 1.45.6 (20-Mar-2020)
>> Resize inode not valid.  Recreate<y>? yes
>> Pass 1: Checking inodes, blocks, and sizes
>> Deleted inode 3681 has zero dtime.  Fix<y>? yes
>> Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
>> Inode 3744 was part of the orphaned inode list.  FIXED.
>> Deleted inode 3745 has zero dtime.  Fix<y>? yes
>> Inode 3747 has INLINE_DATA_FL flag on filesystem without inline data
>> support.
>> Clear<y>? yes
>> Inode 3748 was part of the orphaned inode list.  FIXED.
>> Inode 3748 has a extra size (6144) which is invalid
>> Fix<y>? yes
>> Inode 3751 is in use, but has dtime set.  Fix<y>? yes
>> Inode 3751 has imagic flag set.  Clear<y>? yes
>> Inode 3752 was part of the orphaned inode list.  FIXED.
>> Inode 3753 was part of the orphaned inode list.  FIXED.
>> Inode 3754 is in use, but has dtime set.  Fix<y>? yes
>> Inode 3755 was part of the orphaned inode list.  FIXED.
>> Inode 3755 has imagic flag set.  Clear ('a' enables 'yes' to all) <y>? yes
>> Deleted inode 3801 has zero dtime.  Fix ('a' enables 'yes' to all) <y>?
>> ...
> 
> This sounds like the cause.
> 
> As btrfs completely rely on the used space reported from ext*, and if
> the fs is corrupted, then a lot of things can go wrong.

No, maybe you missed it but I did a fsck before the convert (see above). 
It reported no errors.

Only after the failed btrfs-convert I get the errors.


>>
>>> If you can rollback, would you provide the ext4 fs image?
>>
>> You mean the vmdk from VMware? I do have a backup.
> 
> Would you mind to run e2fsck on the backup first to see if that's the
> problem?

The backup has no fsck issues.

> If the fixed fs can not pass btrfs-convert still, would you mind to send
> the fs image?

How/where would you like me to send it?

Thanks, Christian

> 
> Thanks,
> Qu
> 
>>
>> Thanks!
>>
>> Christian
>>
>>>
>>> Thanks,
>>> Qu
>>>
>>>>
>>>> $ uname -a
>>>> Linux t-arch 5.7.7-arch1-1 #1 SMP PREEMPT Wed, 01 Jul 2020 14:53:16
>>>> +0000 x86_64 GNU/Linux
>>>>
>>>> $ btrfs --version
>>>> btrfs-progs v5.7
>>>
>>
>