Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Stéphane Lesimple wrote on 2015/09/17 20:47 +0200:
> Le 2015-09-17 12:41, Qu Wenruo a écrit :
>>> In the meantime, I've reactivated quotas, umounted the filesystem and
>>> ran a btrfsck on it : as you would expect, there's no qgroup problem
>>> reported so far.
>>
>> At least, rescan code is working without problem.
>>
>>> I'll clear all my snapshots, run an quota rescan, then
>>> re-create them one by one by rsyncing from my ext4 system I still have.
>>> Maybe I'll run into the issue again.
>>>
>>
>> Would you mind to do the following check for each subvolume rsync?
>>
>> 1) Do 'sync; btrfs qgroup show -prce --raw' and save the output
>> 2) Create the needed snapshot
>> 3) Do 'sync; btrfs qgroup show -prce --raw' and save the output
>> 4) Avoid doing IO if possible until step 6)
>> 5) Do 'btrfs quota rescan -w' and save it
>> 6) Do 'sync; btrfs qgroup show -prce --raw' and save the output
>> 7) Rsync data from ext4 to the newly created snapshot
>>
>> The point is, as you mentioned, rescan is working fine, we can compare
>> output from 3), 6) and 1) to see which qgroup accounting number
>> changes.
>>
>> And if differs, which means the qgroup update at write time OR
>> snapshot creation has something wrong, at least we can locate the
>> problem to qgroup update routine or snapshot creation.
>
> I was about to do that, but first there's something that sounds strange
> : I've begun by trashing all my snapshots, then ran a quota rescan, and
> waited for it to complete, to start on a sane base.
> However, this is the output of qgroup show now :

By "trashing", did you mean deleting all the files inside the subvolume?
Or "btrfs subv del"?

>
> qgroupid          rfer                 excl     max_rfer     max_excl
> parent  child
> --------          ----                 ----     --------     --------
> ------  -----
> 0/5              16384                16384         none         none
> ---     ---
> 0/1906   1657848029184        1657848029184         none         none
> ---     ---
> 0/1909    124950921216         124950921216         none         none
> ---     ---
> 0/1911   1054587293696        1054587293696         none         none
> ---     ---
> 0/3270     23727300608          23727300608         none         none
> ---     ---
> 0/3314     23206055936          23206055936         none         none
> ---     ---
> 0/3317     18472996864                    0         none         none
> ---     ---
> 0/3318     22235709440 18446744073708421120         none         none
> ---     ---
> 0/3319     22240333824                    0         none         none
> ---     ---
> 0/3320     22289608704                    0         none         none
> ---     ---
> 0/3321     22289608704                    0         none         none
> ---     ---
> 0/3322     18461151232                    0         none         none
> ---     ---
> 0/3323     18423902208                    0         none         none
> ---     ---
> 0/3324     18423902208                    0         none         none
> ---     ---
> 0/3325     18463506432                    0         none         none
> ---     ---
> 0/3326     18463506432                    0         none         none
> ---     ---
> 0/3327     18463506432                    0         none         none
> ---     ---
> 0/3328     18463506432                    0         none         none
> ---     ---
> 0/3329     18585427968                    0         none         none
> ---     ---
> 0/3330     18621472768 18446744073251348480         none         none
> ---     ---
> 0/3331     18621472768                    0         none         none
> ---     ---
> 0/3332     18621472768                    0         none         none
> ---     ---
> 0/3333     18783076352                    0         none         none
> ---     ---
> 0/3334     18799804416                    0         none         none
> ---     ---
> 0/3335     18799804416                    0         none         none
> ---     ---
> 0/3336     18816217088                    0         none         none
> ---     ---
> 0/3337     18816266240                    0         none         none
> ---     ---
> 0/3338     18816266240                    0         none         none
> ---     ---
> 0/3339     18816266240                    0         none         none
> ---     ---
> 0/3340     18816364544                    0         none         none
> ---     ---
> 0/3341      7530119168           7530119168         none         none
> ---     ---
> 0/3342      4919283712                    0         none         none
> ---     ---
> 0/3343      4921724928                    0         none         none
> ---     ---
> 0/3344      4921724928                    0         none         none
> ---     ---
> 0/3345      6503317504 18446744073690902528         none         none
> ---     ---
> 0/3346      6503452672                    0         none         none
> ---     ---
> 0/3347      6509514752                    0         none         none
> ---     ---
> 0/3348      6515793920                    0         none         none
> ---     ---
> 0/3349      6515793920                    0         none         none
> ---     ---
> 0/3350      6518685696                    0         none         none
> ---     ---
> 0/3351      6521511936                    0         none         none
> ---     ---
> 0/3352      6521511936                    0         none         none
> ---     ---
> 0/3353      6521544704                    0         none         none
> ---     ---
> 0/3354      6597963776                    0         none         none
> ---     ---
> 0/3355      6598275072                    0         none         none
> ---     ---
> 0/3356      6635880448                    0         none         none
> ---     ---
> 0/3357      6635880448                    0         none         none
> ---     ---
> 0/3358      6635880448                    0         none         none
> ---     ---
> 0/3359      6635880448                    0         none         none
> ---     ---
> 0/3360      6635880448                    0         none         none
> ---     ---
> 0/3361      6635880448                    0         none         none
> ---     ---
> 0/3362      6635880448                    0         none         none
> ---     ---
> 0/3363      6635880448                    0         none         none
> ---     ---
> 0/3364      6635880448                    0         none         none
> ---     ---
> 0/3365      6635880448                    0         none         none
> ---     ---
> 0/3366      6635896832                    0         none         none
> ---     ---
> 0/3367     24185790464          24185790464         none         none
> ---     ---
>

Nooooo!! What a wired result here!
Qg 3345 is having minus number again, even after a qgroup rescan....
IIRC, from the code, rescan is just passing old_roots as NULL, and use 
correct new_roots to build up "rfer" and "excl".
So in theory it should never go below zero in rescan.

The only hope for me is, that's a orphan qgroup.(mentioned below)

> I would have expected all these qgroupids to have been trashed with the
> snapshots, but it seems not. It reminded me of the bug you were talking
> about, where deleted snapshots don't always clear correctly their
> qgroup, but as these don't disappear after a rescan either... I'm a bit
> surprised.

If you mean you "btrfs qgroup del" the subvolume, then it's known the 
qgroup won't be deleted, and won't be associated to any subvolume.
(It's possible later created subvolume uses the old subvolid, and be 
associated to the qgroup again).

If above qgroups with 0 or even minus "excl" number are orphan, I'll be 
much relieved, as it'll be a minor orphan qgroup bug other than another 
possible qgroup rework(or at least huge review).

>
> I've just tried quota disable / quota enable, and not it seems OK. Just
> wanted to let you know, in case it's not known behavior ...

Thanks for your info a lot, which indeed expose something we didn't take 
much consideration.

And if the qgroups are the same with above description, would you mind 
to remove these qgroups?

>
> The procedure I'll use will be slighlty different from what you
> proposed, but to my understanding it won't change the result :
>
>> 0) Rsync data from the next ext4 "snapshot" to the subvolume
>> 1) Do 'sync; btrfs qgroup show -prce --raw' and save the output
>> 2) Create the needed readonly snapshot on btrfs
>> 3) Do 'sync; btrfs qgroup show -prce --raw' and save the output
>> 4) Avoid doing IO if possible until step 6)
>> 5) Do 'btrfs quota rescan -w' and save it
>> 6) Do 'sync; btrfs qgroup show -prce --raw' and save the output
>
> I'll post the results once this is done.
>

Thanks a lot!
Qu