Re: [PATCH] fstests: btrfs/022: Disable snapshot ioctl in fsstress

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

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



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@suse.com>
>>>
>>> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]