Re: dev extent physical offset [...] on devid 1 doesn't have corresponding chunk

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

在 2024/12/21 09:41, Ben Millwood 写道:
> Sorry for the delayed reply. I left this for a few days to see how the
> check would get along.
>
> I think probably the terminal I was doing the check in was resized a
> bit, so the output got a little shuffled around, but it now looks like
> this:
>
> root@vigilance:~# btrfs check --progress --mode lowmem
> /dev/masterchef-vg/btrfs
> Opening filesystem to check...
> Checking filesystem on /dev/masterchef-vg/btrfs
> UUID: a0ed3709-1490-4f2d-96b5-bb1fb22f0b45
> [1/7] checking root items                      (0:46:43 elapsed,
> 68928137 items checked)
> [2/7] checking extents                         (14:49:23 elapsed,
> 2419[2/7] checking extents                         (14:49:24 elapsed,
> 2419[
> 2/7] checking extents                         (14:49:25 elapsed,
> 2419[2/7] checking extents                         (14:49:26 elapsed,
> 2419[2
> ERROR: device extent[1, 1997265698816, 576716800] did not find the
> related chunkhecked)
> [2/7] checking extents                         (164:06:57 elapsed,
> 34215503 items checked)
>
> so it looks like the check has noticed the same problem that the mount
> has, at least.
>
> I don't actually understand all this terminology -- is the "items
> checked" number for checking extents counting towards the same total
> as the "root items" number? Or is there any other way of estimating
> how far it needs to count? (Obviously using that to estimate time
> remaining would be highly approximate, but hopefully I could still
> find out if it's measured in weeks or years).
>
> On Sun, 15 Dec 2024 at 04:46, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> Do you still remember if there is any error message for the
>> clear-space-cache interruption and the next RW mount of it?
>
> I can't say confidently at this stage, but I think there was no error
> at clear-space-cache interruption time. I think it's highly possible I
> could have missed an error at my next RW mount attempt, I was probably
> trying a lot of mounts and often only paying attention to the part of
> the error I thought I could debug. (there has been no next
> *successful* mount of this disk, RW or otherwise...)
>
>> Thanks,
>> Qu
>>>
>>> Meanwhile I have created a branch for you to manually fix the bug:
>>> https://github.com/adam900710/btrfs-progs/tree/orphan_dev_extent_cleanup
>>>
>>> Since the lowmem is still running, you can prepare an environment to
>>> build btrfs-progs, so after the lowmem check finished, you can use that
>>> branch to delete the offending item by:
>>>
>>> # ./btrfs-corrupt-block -X <device>
>
> (I have been able to build this but haven't run it yet, since I'm
> still waiting to see if the check says anything interesting)

Please go ahead. Weirdly this error is really a single orphan dev
extent, without any extra other problem.

Thus that command should fix it.

Thanks,
Qu
>
>
>>> Thanks,
>>> Qu
>>>
>>>>>
>>>>> Thanks,
>>>>> Qu
>>>>>
>>>>>> smartctl appears
>>>>>> not to work with this disk, so I can't easily say whether the disk is
>>>>>> or is not healthy.
>>>>>>
>>>>>
>>>
>>>
>>