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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3487 bytes --]



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.

> 
>> 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?

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

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
>>
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]