Re: [PATCH] fstests: btrfs/179 call quota rescan

[Nikolay Borisov <nborisov@suse.com>]

On 10.02.20 г. 3:36 ч., Qu Wenruo wrote:
> 
> 
> On 2020/2/8 下午5:06, Anand Jain wrote:
>>
>>
>> On 2/8/20 7:28 AM, Qu Wenruo wrote:
>>>
>>>
>>> On 2020/2/7 下午11:59, Anand Jain wrote:
>>>>
>>>>
>>>> On 7/2/20 8:15 PM, Qu Wenruo wrote:
>>>>>
>>>>>
>>>>> On 2020/2/7 下午8:01, Anand Jain wrote:
>>>>>> On some systems btrfs/179 fails as the check finds that there is
>>>>>> difference in the qgroup counts.
>>>>>>
>>>>>> By the async nature of qgroup tree scan, the latest qgroup counts
>>>>>> at the
>>>>>> time of umount might not be upto date,
>>>>>
>>>>> Yes, so far so good.
>>>>>
>>>>>> if it isn't then the check will
>>>>>> report the difference in count. The difference in qgroup counts are
>>>>>> anyway
>>>>>> updated in the following mount, so it is not a real issue that this
>>>>>> test
>>>>>> case is trying to verify.
>>>>>
>>>>> No problem either.
>>>>>
>>>>>> So make sure the qgroup counts are updated
>>>>>> before unmount happens and make the check happy.
>>>>>
>>>>> But the solution doesn't look correct to me.
>>>>>
>>>>> We should either make btrfs-check to handle such half-dropped case
>>>>> better,
>>>>
>>>>   Check is ok. The count as check counts matches with the count after
>>>> the
>>>> mount. So what is recorded in the qgroup is not upto date.
>>>
>>> Nope. Qgroup records what's in commit tree. For unmounted fs, there is
>>> no difference in commit tree and current tree.
>>>
>>> Thus the qgroup scan in btrfs-progs is different from kernel.
>>> Please go check how the btrfs-progs code to see how the difference comes.
>>>
>>>>
>>>>> or find a way to wait for all subvolume drop to be finished in
>>>>> test case.
>>>>
>>>> Yes this is one way. Just wait for few seconds will do, test passes. Do
>>>> you know any better way?
>>>
>>> I didn't remember when, but it looks like `btrfs fi sync` used to wait
>>> for snapshot drop.
>>> But not now. If we have a way to wait for cleaner to finish, we can
>>> solve it pretty easily.
>>
>> A sleep at the end of the test case also makes it count consistent.
>> As the intention of the test case is to test for the hang, so sleep 5
>> at the end of the test case is reasonable.
> 
> That looks like a valid workaround.
> 
> Although the immediate number 5 looks no that generic for all test
> environments.
> 
> I really hope to find a stable way to wait for all subvolume drops other
> than rely on some hard coded numbers.

 what about btrfs filesystem sync?


<snip>