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:
signature.asc
Description: OpenPGP digital signature
