Re: ERROR... please contact btrfs developers

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

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



On 2020/10/5 下午8:03, Eric Levy wrote:
> I have two pieces of good news.
> 
> First, after the extents were repaired, a RO mount was sufficient to
> duplicate successfully the subvolumes on other media using the send
> and receive commands.
> 
> Second, with respect to the further problem of the balance operation
> failing, I was able to synchronize the subvolumes by mounting with
> balancing disabled. The effect of this step was to gain 22GB of
> unallocated space. Balancing succeeded after I unmounted and then
> mounted normally.

Great!

> 
> I then began a scrub operation, which completed successfully.

That ensures your data is all good.

Since your previous btrfs check ensures your metadata is also good, and
you freed enough unallocated space, your fs is officially very healthy now.

Really all good news.

> 
> I am hopeful that we may consider this file system healthy, with no
> loss of data due to file system problems. Currently, all the evidence
> suggests as such.
> 
> Needless to say, it would be very valuable to pursue improvements that
> reduce the chances of similar problems for users in the future.

Although I really doubt about the ENOSPC behavior, it looks like
something wrong with the space reserve code, and should not happen for
single device case, at least for latest kernel.

But since now you have enough free space, I guess we can't find out the
result anymore.

Thanks,
Qu

> 
> 
> On Mon, Oct 5, 2020 at 5:17 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2020/10/5 下午5:05, Eric Levy wrote:
>>> The volume is not RAID, only a single NVMe card.
>>
>> Then this means, we may have a bigger problem.
>>
>> Normally btrfs space reservation keeps enough margin for critical
>> operations, thus it will return ENOSPC before we really go to do some
>> space consuming operations, thus no abort_transaction problem like yours.
>>
>> If it's single device, and still hit the case we need more space than we
>> have, either the space reservation or the space consumer,
>> btrfs_drop_snapshot(), has something wrong.
>>>
>>> I deleted all the files and subvolumes except what I need to recover.
>>
>> You may want to wait until btrfs really drops the subvolume/snapshot.
>>
>> The command is "btrfs subv sync <mount>". And then check if the usage drops.
>>


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