Re: ERROR... please contact btrfs developers

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

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



On 2020/10/5 上午9:33, Eric Levy wrote:
> A new observation is that I notice that through the RO option,
> although the mount still degrades after continued use, it is more
> stable than in a standard RW mode. At this point, I believe I have
> recovered the crucial folders, though I have no guarantee that no
> files are missing or corrupted.

As replied, none of your data is lost or corrupted by this incident.

You can reverted to older kernel without the extent item generation
check to continue your usage without any problem.

Also as said, using this branch with "btrfs check --repair" should solve
your problem, and make the fs safe against latest kernel
https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair

Thanks,
Qu


> I would hope to restore this
> filesystem to a fully functional state, or otherwise clone the
> subvolumes successfully to another partition, with as much data
> recovery as possible.
> 
> Even with RO, the receive command still fails rather abruptly, though
> not always immediately:
> 
> ERROR: send ioctl failed with -5: Input/output error
> 
> I have written to the list because I believe that doing so best
> satisfies the request within the error message to "please contact
> btrfs developers". If another avenue of communication is more
> suitable, then please advise.
> 
> On Tue, Sep 29, 2020 at 9:44 PM Eric Levy <ericlevy@gmail.com> wrote:
>>
>> I recently upgraded a Linux system running on btrfs from a 5.3.x
>> kernel to a 5.4.x version. The system failed to run for more than a
>> few minutes after the upgrade, because the root mount degraded to a
>> read-only state. I continued to use the system by booting using the
>> 5.3.x kernel.
>>
>> Some time later, I attempted to migrate the root subvolume using a
>> send-receive command pairing, and noticed that the operation would
>> invariably abort before completion. I also noticed that a full file
>> walk of the mounted volume was impossible, because operations on some
>> files generated errors from the file-system level.
>>
>> Upon investigating using a check command, I learned that the file
>> system had errors.
>>
>> Examining the error report (not saved), I noticed that overall my
>> situation had rather clear similarities to one described in an earlier
>> discussion [1].
>>
>> Unfortunately, it appears that the differences in the kernels may have
>> corrupted the file system.
>>
>> Based on eagerness for a resolution, and on an optimistic comment
>> toward the end of the discussion, I chose to run a check operation on
>> the partition with the --repair flag included.
>>
>> Perhaps not surprisingly to some, the result of a read-only check
>> operation after the attempted repair gave a much more discouraging
>> report, suggesting that the damage to the file system was made worse
>> not better by the operation. I realize that this possibility is
>> explained in the documentation.
>>
>> At the moment, the full report appears as below.
>>
>> Presently, the file system mounts, but the ability to successfully
>> read files degrades the longer the system is mounted and the more
>> files are read during a continuous mount. Experiments involving
>> unmounting and then mounting again give some indication that this
>> degradation is not entirely permanent.
>>
>> What possibility is open to recover all or part of the file system?
>> After such a rescue attempt, would I have any way to know what is lost
>> versus saved? Might I expect corruption within the file contents that
>> would not be detected by the rescue effort?
>>
>> I would be thankful for any guidance that might lead to restoring the data
>>
>>
>> [1] https://www.spinics.net/lists/linux-btrfs/msg96735.html
>> ---
>>
>> Opening filesystem to check...
>> Checking filesystem on /dev/sda5
>> UUID: 9a4da0b6-7e39-4a5f-85eb-74acd11f5b94
>> [1/7] checking root items
>> [2/7] checking extents
>> ERROR: invalid generation for extent 4064026624, have 94810718697136
>> expect (0, 33469925]
>> ERROR: invalid generation for extent 16323178496, have 94811372174048
>> expect (0, 33469925]
>> ERROR: invalid generation for extent 79980945408, have 94811372219744
>> expect (0, 33469925]
>> ERROR: invalid generation for extent 318963990528, have 94810111593504
>> expect (0, 33469925]
>> ERROR: invalid generation for extent 319650189312, have 14758526976
>> expect (0, 33469925]
>> ERROR: invalid generation for extent 319677259776, have 414943019007
>> expect (0, 33469925]
>> ERROR: errors found in extent allocation tree or chunk allocation
>> [3/7] checking free space cache
>> block group 71962722304 has wrong amount of free space, free space
>> cache has 266420224 block group has 266354688
>> ERROR: free space cache has more free space than block group item,
>> this could leads to serious corruption, please contact btrfs
>> developers
>> failed to load free space cache for block group 71962722304
>> [4/7] checking fs roots
>> [5/7] checking only csums items (without verifying data)
>> [6/7] checking root refs
>> [7/7] checking quota groups
>> found 399845548032 bytes used, error(s) found
>> total csum bytes: 349626220
>> total tree bytes: 5908873216
>> total fs tree bytes: 4414324736
>> total extent tree bytes: 879493120
>> btree space waste bytes: 1122882578
>> file data blocks allocated: 550505705472
>>  referenced 512080416768


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