On 2020/7/14 下午5:33, Christian Zangl wrote:
> 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?
Does Google driver work for you?
Thanks,
Qu
>
> 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
>>>>
>>>
>>
>
Attachment:
signature.asc
Description: OpenPGP digital signature
