On 2020/2/7 上午8:38, Josef Bacik wrote:
> On 2/6/20 7:35 PM, Qu Wenruo wrote:
>>
>>
>> On 2020/2/6 下午11:47, Josef Bacik wrote:
>>> On 2/6/20 12:32 AM, Qu Wenruo wrote:
>>>> Since commit fd0830929573 ("fsstress: add the ability to create
>>>> snapshots") adds the ability for fsstress to create/delete snapshot and
>>>> subvolume, test case btrfs/022 fails as _btrfs_get_subvolid can't
>>>> handle multiple subvolumes under the same path.
>>>>
>>>> So manually disable snapshot/subvolume creation and deletion ioctl in
>>>> this
>>>> test case. Other qgroup test cases aren't affected.
>>>>
>>>> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
>>>
>>> Why not just fix _btrfs_get_subvolid? You can use egrep to make sure
>>> the name matches exactly. Thanks,
>>
>> Because we have other requirement, like limit tests.
>>
>> If we have other snapshots/subvolumes, they don't have the same limit,
>> thus unable to test qgroup properly.
>>
>
> That's fair, but we should also fix _btrfs_get_subvolid since we know it
> doesn't work in this case. Thanks,
My bad. It's not the limit test, it doesn't utilize fsstress at all.
It's completely the bad greping for qgroup ids.
We could have the following subvolume layouts in btrfs qgroup show output:
subvol a id=256
subvol b id=306
qgroupid rfer excl
-------- ---- ----
0/5 16384 16384
0/256 13914112 16384
...
0/263 3080192 2306048 << 306 matches here first
...
0/306 13914112 16384 << Then match here
Although disabling snapshot/subvolume creation solves the problem since
there will be no other subvolumes to start with, we're still not that safe.
The root fix is to grep qgroupid by "0/$subvolid", not just $subvolid.
I'll do a proer fix, and keep the snapshot/subvolume creation to take
advantage of your enhanced fsstress.
Thanks,
Qu
>
> Josef
Attachment:
signature.asc
Description: OpenPGP digital signature
