Re: Enabling quota may not correctly rescan on 4.17
> Misono, > > Can you please try the attached patch? > I tried and it works (on 4.18.0-rc3). Committing transaction before starting rescan worker is what btrfs_qgroup_resan() does, so it looks fine. (though I'm not sure why you don't see the problem in your machine.) Reviewed-by: Misono Tomohiro Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 28.06.2018 11:10, Misono Tomohiro wrote:
> On 2018/06/28 16:12, Qu Wenruo wrote:
>>
>>
>> On 2018年06月27日 16:25, Misono Tomohiro wrote:
>>> On 2018/06/27 17:10, Qu Wenruo wrote:
On 2018年06月26日 14:00, Misono Tomohiro wrote:
> Hello Nikolay,
>
> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
> to fail correctly rescanning quota when quota is enabled.
>
> Simple reproducer:
>
> $ mkfs.btrfs -f $DEV
> $ mount $DEV /mnt
> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
> $ btrfs quota enbale /mnt
> $ umount /mnt
> $ btrfs check $DEV
> ...
>> Unfortunately in my environment, btrfs/114 failed to reprocduce it with
>> 1024 runs overnight, with v4.18-rc1 kernel.
>>
>> Would you please provide the whole btrfs-image dump of the corrupted fs?
>
> Yes.
> The attached file is an image-dump of above reproducer (kernel 4.17.0, progs
> 4.17)
> as the dump of btrfs/114 is a bit large for mail.
>
> Though this does not always happen, I see the failure both on 4.17.0 or
> 4.18-rc2.
>
> Thanks,
> Tomohiro Misono
Misono,
Can you please try the attached patch?
>
>>
>> There are several different assumptions on how the bug happens, with
>> your btrfs-image dump, it would help a lot to rule out some assumption.
>>
>> Thanks,
>> Qu
>From 10345e21bc2b4e61644da6b76ee4528710b2be25 Mon Sep 17 00:00:00 2001
From: Nikolay Borisov
Date: Tue, 26 Jun 2018 10:03:58 +0300
Subject: [PATCH] btrfs: qgroups: Move transaction managed inside
btrfs_quota_enable/disable
Commit 5d23515be669 ("btrfs: Move qgroup rescan on quota enable to
btrfs_quota_enable") not only resulted in an easier to follow code but
it also introduced a subtle bug. It changed the timing when the initial
transaction rescan was happening - before the commit it would happen
after transaction commit had occured but after the commit it might happen
before the transaction was committed. This results in failure to
correctly rescan the quota since there could be data which is still not
committed on disk.
This patch aims to fix this by movign the transaction creation/commit
inside btrfs_quota_enable, which allows to schedule the quota commit
after the transaction has been committed. For the sake of symmetry this patch
also moves the transaction logic inside btrfs_quota_disable
Fixes: 5d23515be669 ("btrfs: Move qgroup rescan on quota enable to btrfs_quota_enable")
Reported-by: Misono Tomohiro
Link: https://marc.info/?l=linux-btrfs&m=152999289017582
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ioctl.c | 15 ++-
fs/btrfs/qgroup.c | 38 +++---
fs/btrfs/qgroup.h | 6 ++
3 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index a399750b9e41..316fb1af15e2 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -5135,9 +5135,7 @@ static long btrfs_ioctl_quota_ctl(struct file *file, void __user *arg)
struct inode *inode = file_inode(file);
struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
struct btrfs_ioctl_quota_ctl_args *sa;
- struct btrfs_trans_handle *trans = NULL;
int ret;
- int err;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -5153,28 +5151,19 @@ static long btrfs_ioctl_quota_ctl(struct file *file, void __user *arg)
}
down_write(&fs_info->subvol_sem);
- trans = btrfs_start_transaction(fs_info->tree_root, 2);
- if (IS_ERR(trans)) {
- ret = PTR_ERR(trans);
- goto out;
- }
switch (sa->cmd) {
case BTRFS_QUOTA_CTL_ENABLE:
- ret = btrfs_quota_enable(trans, fs_info);
+ ret = btrfs_quota_enable(fs_info);
break;
case BTRFS_QUOTA_CTL_DISABLE:
- ret = btrfs_quota_disable(trans, fs_info);
+ ret = btrfs_quota_disable(fs_info);
break;
default:
ret = -EINVAL;
break;
}
- err = btrfs_commit_transaction(trans);
- if (err && !ret)
- ret = err;
-out:
kfree(sa);
up_write(&fs_info->subvol_sem);
drop_write:
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index 1874a6d2e6f5..1d84af0d053f 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -875,8 +875,7 @@ static int btrfs_clean_quota_tree(struct btrfs_trans_handle *trans,
return ret;
}
-int btrfs_quota_enable(struct btrfs_trans_handle *trans,
- struct btrfs_fs_info *fs_info)
+int btrfs_quota_enable(struct btrfs_fs_info *fs_info)
{
struct btrfs_root *quota_root;
struct btrfs_root *tree_root = fs_info->tree_root;
@@ -886,6 +885,7 @@ int btrfs_quota_enable(struct btrfs_trans_handle *trans,
struct btrfs_key key;
struct btrfs_key found_key;
struct btrfs_qgroup *qgroup = NULL;
+ struct btrfs_trans_handle *trans = NULL;
int ret = 0;
int slot;
@@ -893,6 +893,12 @@ int btrfs_quota_enable(struct btrfs_trans_handle *trans,
if (fs_info->quota_root)
goto out;
+ trans = btrfs_start_transaction(tree_root, 2);
+ if (IS_ERR(trans)) {
+ ret = PTR_ERR(trans);
+ goto out;
+ }
+
fs_info->qgr
Re: Enabling quota may not correctly rescan on 4.17
On 2018/06/28 16:12, Qu Wenruo wrote:
>
>
> On 2018年06月27日 16:25, Misono Tomohiro wrote:
>> On 2018/06/27 17:10, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月26日 14:00, Misono Tomohiro wrote:
Hello Nikolay,
I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
to fail correctly rescanning quota when quota is enabled.
Simple reproducer:
$ mkfs.btrfs -f $DEV
$ mount $DEV /mnt
$ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
$ btrfs quota enbale /mnt
$ umount /mnt
$ btrfs check $DEV
...
> Unfortunately in my environment, btrfs/114 failed to reprocduce it with
> 1024 runs overnight, with v4.18-rc1 kernel.
>
> Would you please provide the whole btrfs-image dump of the corrupted fs?
Yes.
The attached file is an image-dump of above reproducer (kernel 4.17.0, progs
4.17)
as the dump of btrfs/114 is a bit large for mail.
Though this does not always happen, I see the failure both on 4.17.0 or
4.18-rc2.
Thanks,
Tomohiro Misono
>
> There are several different assumptions on how the bug happens, with
> your btrfs-image dump, it would help a lot to rule out some assumption.
>
> Thanks,
> Qu
btrfs-image
Description: Binary data
Re: Enabling quota may not correctly rescan on 4.17
On 2018年06月27日 16:25, Misono Tomohiro wrote:
> On 2018/06/27 17:10, Qu Wenruo wrote:
>>
>>
>> On 2018年06月26日 14:00, Misono Tomohiro wrote:
>>> Hello Nikolay,
>>>
>>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>>> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
>>> to fail correctly rescanning quota when quota is enabled.
>>>
>>> Simple reproducer:
>>>
>>> $ mkfs.btrfs -f $DEV
>>> $ mount $DEV /mnt
>>> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
>>> $ btrfs quota enbale /mnt
>>> $ umount /mnt
>>> $ btrfs check $DEV
>>> ...
>>> checking quota groups
>>> Counts for qgroup id: 0/5 are different
>>> our:referenced 1019904 referenced compressed 1019904
>>> disk: referenced 16384 referenced compressed 16384
>>> diff: referenced 1003520 referenced compressed 1003520
>>> our:exclusive 1019904 exclusive compressed 1019904
>>> disk: exclusive 16384 exclusive compressed 16384
>>> diff: exclusive 1003520 exclusive compressed 1003520
>>> found 1413120 bytes used, error(s) found
>>> ...
>>>
>>> This can be also observed in btrfs/114. (Note that progs < 4.17
>>> returns error code 0 even if quota is not consistency and therefore
>>> test will incorrectly pass.)
>>
>> BTW, would you please try to dump the quota tree for such mismatch case?
>>
>> It could be a btrfs-progs bug which it should skip quota checking if it
>> found the quota status item has RESCAN flag.
>
> Yes, this is what I see after running btrfs/114 (/dev/sdh1 is scratch dev):
>
> $ sudo btrfs check -Q /dev/sdh1
> Checking filesystem on /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Print quota groups for /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Counts for qgroup id: 0/5 are different
> our:referenced 170999808 referenced compressed 170999808
> disk: referenced 16384 referenced compressed 16384
> diff: referenced 170983424 referenced compressed 170983424
> our:exclusive 170999808 exclusive compressed 170999808
> disk: exclusive 16384 exclusive compressed 16384
> diff: exclusive 170983424 exclusive compressed 170983424
>
Unfortunately in my environment, btrfs/114 failed to reproduce it with
1024 runs overnight, with v4.18-rc1 kernel.
Would you please provide the whole btrfs-image dump of the corrupted fs?
There are several different assumptions on how the bug happens, with
your btrfs-image dump, it would help a lot to rule out some assumption.
Thanks,
Qu
>
> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
> btrfs-progs v4.17
> quota tree key (QUOTA_TREE ROOT_ITEM 0)
> leaf 213958656 items 3 free space 16096 generation 9 owner QUOTA_TREE
> leaf 213958656 flags 0x1(WRITTEN) backref revision 1
> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
> version 1 generation 9 flags ON scan 30572545
> item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
> generation 7
> referenced 16384 referenced_compressed 16384
> exclusive 16384 exclusive_compressed 16384
> item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
> flags 0
> max_referenced 0 max_exclusive 0
> rsv_referenced 0 rsv_exclusive 0
> total bytes 26843545600
> bytes used 171769856
> uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>
>
> And if I mount+rescan again:
>
> $ sudo mount /dev/sdh1 /mnt
> $ sudo btrfs quota rescan -w /mnt
> $ sudo umount /mnt
>
> $ sudo btrfs check -Q /dev/sdh1
> Checking filesystem on /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Print quota groups for /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Counts for qgroup id: 0/5
> our:referenced 170999808 referenced compressed 170999808
> disk: referenced 170999808 referenced compressed 170999808
> our:exclusive 170999808 exclusive compressed 170999808
> disk: exclusive 170999808 exclusive compressed 170999808
>
> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
> btrfs-progs v4.17
> quota tree key (QUOTA_TREE ROOT_ITEM 0)
> leaf 31309824 items 3 free space 16096 generation 13 owner QUOTA_TREE
> leaf 31309824 flags 0x1(WRITTEN) backref revision 1
> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
> version 1 generation 13 flags ON scan 213827585
> item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
> generation 11
> referenced 170999808 referenced_compressed 170999808
> exclusive 170999808 exclusive_compressed 170999808
> item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
> flags 0
>
Re: Enabling quota may not correctly rescan on 4.17
On 2018年06月27日 16:57, Qu Wenruo wrote:
>
>
> On 2018年06月27日 16:47, Nikolay Borisov wrote:
>>
>>
>> On 27.06.2018 11:38, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月27日 16:34, Qu Wenruo wrote:
On 2018年06月27日 16:25, Misono Tomohiro wrote:
> On 2018/06/27 17:10, Qu Wenruo wrote:
>>
>>
>> On 2018年06月26日 14:00, Misono Tomohiro wrote:
>>> Hello Nikolay,
>>>
>>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>>> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
>>> to fail correctly rescanning quota when quota is enabled.
>>>
>>> Simple reproducer:
>>>
>>> $ mkfs.btrfs -f $DEV
>>> $ mount $DEV /mnt
>>> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
>>> $ btrfs quota enbale /mnt
>>> $ umount /mnt
>>> $ btrfs check $DEV
>>> ...
>>> checking quota groups
>>> Counts for qgroup id: 0/5 are different
>>> our:referenced 1019904 referenced compressed 1019904
>>> disk: referenced 16384 referenced compressed 16384
>>> diff: referenced 1003520 referenced compressed 1003520
>>> our:exclusive 1019904 exclusive compressed 1019904
>>> disk: exclusive 16384 exclusive compressed 16384
>>> diff: exclusive 1003520 exclusive compressed 1003520
>>> found 1413120 bytes used, error(s) found
>>> ...
>>>
>>> This can be also observed in btrfs/114. (Note that progs < 4.17
>>> returns error code 0 even if quota is not consistency and therefore
>>> test will incorrectly pass.)
>>
>> BTW, would you please try to dump the quota tree for such mismatch case?
>>
>> It could be a btrfs-progs bug which it should skip quota checking if it
>> found the quota status item has RESCAN flag.
>
> Yes, this is what I see after running btrfs/114 (/dev/sdh1 is scratch
> dev):
>
> $ sudo btrfs check -Q /dev/sdh1
> Checking filesystem on /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Print quota groups for /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Counts for qgroup id: 0/5 are different
> our:referenced 170999808 referenced compressed 170999808
> disk: referenced 16384 referenced compressed 16384
> diff: referenced 170983424 referenced compressed 170983424
> our:exclusive 170999808 exclusive compressed 170999808
> disk: exclusive 16384 exclusive compressed 16384
> diff: exclusive 170983424 exclusive compressed 170983424
>
>
> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
> btrfs-progs v4.17
> quota tree key (QUOTA_TREE ROOT_ITEM 0)
> leaf 213958656 items 3 free space 16096 generation 9 owner QUOTA_TREE
> leaf 213958656 flags 0x1(WRITTEN) backref revision 1
> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
> version 1 generation 9 flags ON scan 30572545
Scan is not -1 and flags is only ON, without RESCAN.
> item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
> generation 7
> referenced 16384 referenced_compressed 16384
> exclusive 16384 exclusive_compressed 16384
> item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
> flags 0
> max_referenced 0 max_exclusive 0
> rsv_referenced 0 rsv_exclusive 0
> total bytes 26843545600
> bytes used 171769856
> uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>
>
> And if I mount+rescan again:
>
> $ sudo mount /dev/sdh1 /mnt
> $ sudo btrfs quota rescan -w /mnt
> $ sudo umount /mnt
>
> $ sudo btrfs check -Q /dev/sdh1
> Checking filesystem on /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Print quota groups for /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Counts for qgroup id: 0/5
> our:referenced 170999808 referenced compressed 170999808
> disk: referenced 170999808 referenced compressed 170999808
> our:exclusive 170999808 exclusive compressed 170999808
> disk: exclusive 170999808 exclusive compressed 170999808
>
> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
> btrfs-progs v4.17
> quota tree key (QUOTA_TREE ROOT_ITEM 0)
> leaf 31309824 items 3 free space 16096 generation 13 owner QUOTA_TREE
> leaf 31309824 flags 0x1(WRITTEN) backref revision 1
> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
> version 1 generation 13 flags ON scan 213827585
Re: Enabling quota may not correctly rescan on 4.17
On 2018年06月27日 16:47, Nikolay Borisov wrote:
>
>
> On 27.06.2018 11:38, Qu Wenruo wrote:
>>
>>
>> On 2018年06月27日 16:34, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月27日 16:25, Misono Tomohiro wrote:
On 2018/06/27 17:10, Qu Wenruo wrote:
>
>
> On 2018年06月26日 14:00, Misono Tomohiro wrote:
>> Hello Nikolay,
>>
>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
>> to fail correctly rescanning quota when quota is enabled.
>>
>> Simple reproducer:
>>
>> $ mkfs.btrfs -f $DEV
>> $ mount $DEV /mnt
>> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
>> $ btrfs quota enbale /mnt
>> $ umount /mnt
>> $ btrfs check $DEV
>> ...
>> checking quota groups
>> Counts for qgroup id: 0/5 are different
>> our:referenced 1019904 referenced compressed 1019904
>> disk: referenced 16384 referenced compressed 16384
>> diff: referenced 1003520 referenced compressed 1003520
>> our:exclusive 1019904 exclusive compressed 1019904
>> disk: exclusive 16384 exclusive compressed 16384
>> diff: exclusive 1003520 exclusive compressed 1003520
>> found 1413120 bytes used, error(s) found
>> ...
>>
>> This can be also observed in btrfs/114. (Note that progs < 4.17
>> returns error code 0 even if quota is not consistency and therefore
>> test will incorrectly pass.)
>
> BTW, would you please try to dump the quota tree for such mismatch case?
>
> It could be a btrfs-progs bug which it should skip quota checking if it
> found the quota status item has RESCAN flag.
Yes, this is what I see after running btrfs/114 (/dev/sdh1 is scratch dev):
$ sudo btrfs check -Q /dev/sdh1
Checking filesystem on /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Print quota groups for /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Counts for qgroup id: 0/5 are different
our:referenced 170999808 referenced compressed 170999808
disk: referenced 16384 referenced compressed 16384
diff: referenced 170983424 referenced compressed 170983424
our:exclusive 170999808 exclusive compressed 170999808
disk: exclusive 16384 exclusive compressed 16384
diff: exclusive 170983424 exclusive compressed 170983424
$ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
btrfs-progs v4.17
quota tree key (QUOTA_TREE ROOT_ITEM 0)
leaf 213958656 items 3 free space 16096 generation 9 owner QUOTA_TREE
leaf 213958656 flags 0x1(WRITTEN) backref revision 1
fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
version 1 generation 9 flags ON scan 30572545
>>>
>>> Scan is not -1 and flags is only ON, without RESCAN.
>>>
item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
generation 7
referenced 16384 referenced_compressed 16384
exclusive 16384 exclusive_compressed 16384
item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
flags 0
max_referenced 0 max_exclusive 0
rsv_referenced 0 rsv_exclusive 0
total bytes 26843545600
bytes used 171769856
uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
And if I mount+rescan again:
$ sudo mount /dev/sdh1 /mnt
$ sudo btrfs quota rescan -w /mnt
$ sudo umount /mnt
$ sudo btrfs check -Q /dev/sdh1
Checking filesystem on /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Print quota groups for /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Counts for qgroup id: 0/5
our:referenced 170999808 referenced compressed 170999808
disk: referenced 170999808 referenced compressed 170999808
our:exclusive 170999808 exclusive compressed 170999808
disk: exclusive 170999808 exclusive compressed 170999808
$ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
btrfs-progs v4.17
quota tree key (QUOTA_TREE ROOT_ITEM 0)
leaf 31309824 items 3 free space 16096 generation 13 owner QUOTA_TREE
leaf 31309824 flags 0x1(WRITTEN) backref revision 1
fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
version 1 generation 13 flags ON scan 213827585
>>>
>>> Still doesn't look good.
>>>
>>> In v4.17.2 (sorry, just checking the behavior on my host), after correct
>>> rescan + sync, if we don't have RESCAN flag, we s
Re: Enabling quota may not correctly rescan on 4.17
On 27.06.2018 11:38, Qu Wenruo wrote:
>
>
> On 2018年06月27日 16:34, Qu Wenruo wrote:
>>
>>
>> On 2018年06月27日 16:25, Misono Tomohiro wrote:
>>> On 2018/06/27 17:10, Qu Wenruo wrote:
On 2018年06月26日 14:00, Misono Tomohiro wrote:
> Hello Nikolay,
>
> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
> to fail correctly rescanning quota when quota is enabled.
>
> Simple reproducer:
>
> $ mkfs.btrfs -f $DEV
> $ mount $DEV /mnt
> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
> $ btrfs quota enbale /mnt
> $ umount /mnt
> $ btrfs check $DEV
> ...
> checking quota groups
> Counts for qgroup id: 0/5 are different
> our:referenced 1019904 referenced compressed 1019904
> disk: referenced 16384 referenced compressed 16384
> diff: referenced 1003520 referenced compressed 1003520
> our:exclusive 1019904 exclusive compressed 1019904
> disk: exclusive 16384 exclusive compressed 16384
> diff: exclusive 1003520 exclusive compressed 1003520
> found 1413120 bytes used, error(s) found
> ...
>
> This can be also observed in btrfs/114. (Note that progs < 4.17
> returns error code 0 even if quota is not consistency and therefore
> test will incorrectly pass.)
BTW, would you please try to dump the quota tree for such mismatch case?
It could be a btrfs-progs bug which it should skip quota checking if it
found the quota status item has RESCAN flag.
>>>
>>> Yes, this is what I see after running btrfs/114 (/dev/sdh1 is scratch dev):
>>>
>>> $ sudo btrfs check -Q /dev/sdh1
>>> Checking filesystem on /dev/sdh1
>>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>> Print quota groups for /dev/sdh1
>>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>> Counts for qgroup id: 0/5 are different
>>> our:referenced 170999808 referenced compressed 170999808
>>> disk: referenced 16384 referenced compressed 16384
>>> diff: referenced 170983424 referenced compressed 170983424
>>> our:exclusive 170999808 exclusive compressed 170999808
>>> disk: exclusive 16384 exclusive compressed 16384
>>> diff: exclusive 170983424 exclusive compressed 170983424
>>>
>>>
>>> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
>>> btrfs-progs v4.17
>>> quota tree key (QUOTA_TREE ROOT_ITEM 0)
>>> leaf 213958656 items 3 free space 16096 generation 9 owner QUOTA_TREE
>>> leaf 213958656 flags 0x1(WRITTEN) backref revision 1
>>> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
>>> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
>>> version 1 generation 9 flags ON scan 30572545
>>
>> Scan is not -1 and flags is only ON, without RESCAN.
>>
>>> item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
>>> generation 7
>>> referenced 16384 referenced_compressed 16384
>>> exclusive 16384 exclusive_compressed 16384
>>> item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
>>> flags 0
>>> max_referenced 0 max_exclusive 0
>>> rsv_referenced 0 rsv_exclusive 0
>>> total bytes 26843545600
>>> bytes used 171769856
>>> uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>>
>>>
>>> And if I mount+rescan again:
>>>
>>> $ sudo mount /dev/sdh1 /mnt
>>> $ sudo btrfs quota rescan -w /mnt
>>> $ sudo umount /mnt
>>>
>>> $ sudo btrfs check -Q /dev/sdh1
>>> Checking filesystem on /dev/sdh1
>>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>> Print quota groups for /dev/sdh1
>>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>> Counts for qgroup id: 0/5
>>> our:referenced 170999808 referenced compressed 170999808
>>> disk: referenced 170999808 referenced compressed 170999808
>>> our:exclusive 170999808 exclusive compressed 170999808
>>> disk: exclusive 170999808 exclusive compressed 170999808
>>>
>>> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
>>> btrfs-progs v4.17
>>> quota tree key (QUOTA_TREE ROOT_ITEM 0)
>>> leaf 31309824 items 3 free space 16096 generation 13 owner QUOTA_TREE
>>> leaf 31309824 flags 0x1(WRITTEN) backref revision 1
>>> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
>>> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
>>> version 1 generation 13 flags ON scan 213827585
>>
>> Still doesn't look good.
>>
>> In v4.17.2 (sorry, just checking the behavior on my host), after correct
>> rescan + sync, if we don't have RESCAN flag, we should have scan set to -1.
>>
>> While in in v4.18-rc1, it doesn't reset the scan progress to -1 after
>> finished.
>> And just as explained in previous reply, if later
Re: Enabling quota may not correctly rescan on 4.17
On 2018年06月27日 16:34, Qu Wenruo wrote:
>
>
> On 2018年06月27日 16:25, Misono Tomohiro wrote:
>> On 2018/06/27 17:10, Qu Wenruo wrote:
>>>
>>>
>>> On 2018年06月26日 14:00, Misono Tomohiro wrote:
Hello Nikolay,
I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
to fail correctly rescanning quota when quota is enabled.
Simple reproducer:
$ mkfs.btrfs -f $DEV
$ mount $DEV /mnt
$ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
$ btrfs quota enbale /mnt
$ umount /mnt
$ btrfs check $DEV
...
checking quota groups
Counts for qgroup id: 0/5 are different
our:referenced 1019904 referenced compressed 1019904
disk: referenced 16384 referenced compressed 16384
diff: referenced 1003520 referenced compressed 1003520
our:exclusive 1019904 exclusive compressed 1019904
disk: exclusive 16384 exclusive compressed 16384
diff: exclusive 1003520 exclusive compressed 1003520
found 1413120 bytes used, error(s) found
...
This can be also observed in btrfs/114. (Note that progs < 4.17
returns error code 0 even if quota is not consistency and therefore
test will incorrectly pass.)
>>>
>>> BTW, would you please try to dump the quota tree for such mismatch case?
>>>
>>> It could be a btrfs-progs bug which it should skip quota checking if it
>>> found the quota status item has RESCAN flag.
>>
>> Yes, this is what I see after running btrfs/114 (/dev/sdh1 is scratch dev):
>>
>> $ sudo btrfs check -Q /dev/sdh1
>> Checking filesystem on /dev/sdh1
>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>> Print quota groups for /dev/sdh1
>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>> Counts for qgroup id: 0/5 are different
>> our:referenced 170999808 referenced compressed 170999808
>> disk: referenced 16384 referenced compressed 16384
>> diff: referenced 170983424 referenced compressed 170983424
>> our:exclusive 170999808 exclusive compressed 170999808
>> disk: exclusive 16384 exclusive compressed 16384
>> diff: exclusive 170983424 exclusive compressed 170983424
>>
>>
>> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
>> btrfs-progs v4.17
>> quota tree key (QUOTA_TREE ROOT_ITEM 0)
>> leaf 213958656 items 3 free space 16096 generation 9 owner QUOTA_TREE
>> leaf 213958656 flags 0x1(WRITTEN) backref revision 1
>> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
>> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
>> version 1 generation 9 flags ON scan 30572545
>
> Scan is not -1 and flags is only ON, without RESCAN.
>
>> item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
>> generation 7
>> referenced 16384 referenced_compressed 16384
>> exclusive 16384 exclusive_compressed 16384
>> item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
>> flags 0
>> max_referenced 0 max_exclusive 0
>> rsv_referenced 0 rsv_exclusive 0
>> total bytes 26843545600
>> bytes used 171769856
>> uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>>
>>
>> And if I mount+rescan again:
>>
>> $ sudo mount /dev/sdh1 /mnt
>> $ sudo btrfs quota rescan -w /mnt
>> $ sudo umount /mnt
>>
>> $ sudo btrfs check -Q /dev/sdh1
>> Checking filesystem on /dev/sdh1
>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>> Print quota groups for /dev/sdh1
>> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>> Counts for qgroup id: 0/5
>> our:referenced 170999808 referenced compressed 170999808
>> disk: referenced 170999808 referenced compressed 170999808
>> our:exclusive 170999808 exclusive compressed 170999808
>> disk: exclusive 170999808 exclusive compressed 170999808
>>
>> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
>> btrfs-progs v4.17
>> quota tree key (QUOTA_TREE ROOT_ITEM 0)
>> leaf 31309824 items 3 free space 16096 generation 13 owner QUOTA_TREE
>> leaf 31309824 flags 0x1(WRITTEN) backref revision 1
>> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
>> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
>> version 1 generation 13 flags ON scan 213827585
>
> Still doesn't look good.
>
> In v4.17.2 (sorry, just checking the behavior on my host), after correct
> rescan + sync, if we don't have RESCAN flag, we should have scan set to -1.
>
> While in in v4.18-rc1, it doesn't reset the scan progress to -1 after
> finished.
> And just as explained in previous reply, if later dirty extents are
> after scan progress, it won't be accounted.
> So this explains everything.
>
> We just need to find why scan progress is not set correc
Re: Enabling quota may not correctly rescan on 4.17
On 2018年06月27日 16:25, Misono Tomohiro wrote:
> On 2018/06/27 17:10, Qu Wenruo wrote:
>>
>>
>> On 2018年06月26日 14:00, Misono Tomohiro wrote:
>>> Hello Nikolay,
>>>
>>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>>> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
>>> to fail correctly rescanning quota when quota is enabled.
>>>
>>> Simple reproducer:
>>>
>>> $ mkfs.btrfs -f $DEV
>>> $ mount $DEV /mnt
>>> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
>>> $ btrfs quota enbale /mnt
>>> $ umount /mnt
>>> $ btrfs check $DEV
>>> ...
>>> checking quota groups
>>> Counts for qgroup id: 0/5 are different
>>> our:referenced 1019904 referenced compressed 1019904
>>> disk: referenced 16384 referenced compressed 16384
>>> diff: referenced 1003520 referenced compressed 1003520
>>> our:exclusive 1019904 exclusive compressed 1019904
>>> disk: exclusive 16384 exclusive compressed 16384
>>> diff: exclusive 1003520 exclusive compressed 1003520
>>> found 1413120 bytes used, error(s) found
>>> ...
>>>
>>> This can be also observed in btrfs/114. (Note that progs < 4.17
>>> returns error code 0 even if quota is not consistency and therefore
>>> test will incorrectly pass.)
>>
>> BTW, would you please try to dump the quota tree for such mismatch case?
>>
>> It could be a btrfs-progs bug which it should skip quota checking if it
>> found the quota status item has RESCAN flag.
>
> Yes, this is what I see after running btrfs/114 (/dev/sdh1 is scratch dev):
>
> $ sudo btrfs check -Q /dev/sdh1
> Checking filesystem on /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Print quota groups for /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Counts for qgroup id: 0/5 are different
> our:referenced 170999808 referenced compressed 170999808
> disk: referenced 16384 referenced compressed 16384
> diff: referenced 170983424 referenced compressed 170983424
> our:exclusive 170999808 exclusive compressed 170999808
> disk: exclusive 16384 exclusive compressed 16384
> diff: exclusive 170983424 exclusive compressed 170983424
>
>
> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
> btrfs-progs v4.17
> quota tree key (QUOTA_TREE ROOT_ITEM 0)
> leaf 213958656 items 3 free space 16096 generation 9 owner QUOTA_TREE
> leaf 213958656 flags 0x1(WRITTEN) backref revision 1
> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
> version 1 generation 9 flags ON scan 30572545
Scan is not -1 and flags is only ON, without RESCAN.
> item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
> generation 7
> referenced 16384 referenced_compressed 16384
> exclusive 16384 exclusive_compressed 16384
> item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
> flags 0
> max_referenced 0 max_exclusive 0
> rsv_referenced 0 rsv_exclusive 0
> total bytes 26843545600
> bytes used 171769856
> uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>
>
> And if I mount+rescan again:
>
> $ sudo mount /dev/sdh1 /mnt
> $ sudo btrfs quota rescan -w /mnt
> $ sudo umount /mnt
>
> $ sudo btrfs check -Q /dev/sdh1
> Checking filesystem on /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Print quota groups for /dev/sdh1
> UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> Counts for qgroup id: 0/5
> our:referenced 170999808 referenced compressed 170999808
> disk: referenced 170999808 referenced compressed 170999808
> our:exclusive 170999808 exclusive compressed 170999808
> disk: exclusive 170999808 exclusive compressed 170999808
>
> $ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
> btrfs-progs v4.17
> quota tree key (QUOTA_TREE ROOT_ITEM 0)
> leaf 31309824 items 3 free space 16096 generation 13 owner QUOTA_TREE
> leaf 31309824 flags 0x1(WRITTEN) backref revision 1
> fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
> chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
> item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
> version 1 generation 13 flags ON scan 213827585
Still doesn't look good.
In v4.17.2 (sorry, just checking the behavior on my host), after correct
rescan + sync, if we don't have RESCAN flag, we should have scan set to -1.
While in in v4.18-rc1, it doesn't reset the scan progress to -1 after
finished.
And just as explained in previous reply, if later dirty extents are
after scan progress, it won't be accounted.
So this explains everything.
We just need to find why scan progress is not set correctly after rescan
is finished.
Thanks,
Qu
> item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
> generation 11
> referenced 17
Re: Enabling quota may not correctly rescan on 4.17
On 2018/06/27 17:22, Nikolay Borisov wrote: > > > On 27.06.2018 11:20, Misono Tomohiro wrote: >> I can see the failure with or without options... >> maybe it depends on machine spec? > > I'm testing in a virtual machine: > > qemu-system-x86_64 -smp 6 -kernel > /home/nborisov/projects/kernel/source/arch/x86_64/boot/bzImage -append > root=/dev/vda rw -enable-kvm -m 4096 -drive > file=/home/nborisov/projects/qemu/rootfs/ubuntu15.img,if=virtio -virtfs > local,id=fsdev1,path=/mnt/vm_share,security_model=passthrough,mount_tag=hostshare > -drive file=/home/nborisov/scratch/scratch-images/btrfs-test.img,if=virtio > -drive file=/home/nborisov/scratch/scratch-images/scratch2.img,if=virtio > -drive file=/home/nborisov/scratch/scratch-images/scratch3.img,if=virtio > -drive file=/home/nborisov/scratch/scratch-images/scratch4.img,if=virtio > -drive file=/home/nborisov/scratch/scratch-images/scratch5.img,if=virtio > -drive file=/home/nborisov/scratch/scratch-images/scratch6.img,if=virtio > -redir tcp:1235::22 -daemonize > > Perhaps it's not visible on slow storage. Are you testing on NVME or > something like that? No, I use sata ssd and hdd and the problem can be seen on both. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 2018/06/27 17:10, Qu Wenruo wrote:
>
>
> On 2018年06月26日 14:00, Misono Tomohiro wrote:
>> Hello Nikolay,
>>
>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
>> to fail correctly rescanning quota when quota is enabled.
>>
>> Simple reproducer:
>>
>> $ mkfs.btrfs -f $DEV
>> $ mount $DEV /mnt
>> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
>> $ btrfs quota enbale /mnt
>> $ umount /mnt
>> $ btrfs check $DEV
>> ...
>> checking quota groups
>> Counts for qgroup id: 0/5 are different
>> our:referenced 1019904 referenced compressed 1019904
>> disk: referenced 16384 referenced compressed 16384
>> diff: referenced 1003520 referenced compressed 1003520
>> our:exclusive 1019904 exclusive compressed 1019904
>> disk: exclusive 16384 exclusive compressed 16384
>> diff: exclusive 1003520 exclusive compressed 1003520
>> found 1413120 bytes used, error(s) found
>> ...
>>
>> This can be also observed in btrfs/114. (Note that progs < 4.17
>> returns error code 0 even if quota is not consistency and therefore
>> test will incorrectly pass.)
>
> BTW, would you please try to dump the quota tree for such mismatch case?
>
> It could be a btrfs-progs bug which it should skip quota checking if it
> found the quota status item has RESCAN flag.
Yes, this is what I see after running btrfs/114 (/dev/sdh1 is scratch dev):
$ sudo btrfs check -Q /dev/sdh1
Checking filesystem on /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Print quota groups for /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Counts for qgroup id: 0/5 are different
our:referenced 170999808 referenced compressed 170999808
disk: referenced 16384 referenced compressed 16384
diff: referenced 170983424 referenced compressed 170983424
our:exclusive 170999808 exclusive compressed 170999808
disk: exclusive 16384 exclusive compressed 16384
diff: exclusive 170983424 exclusive compressed 170983424
$ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
btrfs-progs v4.17
quota tree key (QUOTA_TREE ROOT_ITEM 0)
leaf 213958656 items 3 free space 16096 generation 9 owner QUOTA_TREE
leaf 213958656 flags 0x1(WRITTEN) backref revision 1
fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
version 1 generation 9 flags ON scan 30572545
item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
generation 7
referenced 16384 referenced_compressed 16384
exclusive 16384 exclusive_compressed 16384
item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
flags 0
max_referenced 0 max_exclusive 0
rsv_referenced 0 rsv_exclusive 0
total bytes 26843545600
bytes used 171769856
uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
And if I mount+rescan again:
$ sudo mount /dev/sdh1 /mnt
$ sudo btrfs quota rescan -w /mnt
$ sudo umount /mnt
$ sudo btrfs check -Q /dev/sdh1
Checking filesystem on /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Print quota groups for /dev/sdh1
UUID: d07f6028-0ae7-40d4-ac45-01a4505ddcfb
Counts for qgroup id: 0/5
our:referenced 170999808 referenced compressed 170999808
disk: referenced 170999808 referenced compressed 170999808
our:exclusive 170999808 exclusive compressed 170999808
disk: exclusive 170999808 exclusive compressed 170999808
$ sudo btrfs inspect-internal dump-tree -t quota /dev/sdh1
btrfs-progs v4.17
quota tree key (QUOTA_TREE ROOT_ITEM 0)
leaf 31309824 items 3 free space 16096 generation 13 owner QUOTA_TREE
leaf 31309824 flags 0x1(WRITTEN) backref revision 1
fs uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
chunk uuid 78d753d0-eeb7-4c3e-b825-b6c2c5de5c7a
item 0 key (0 QGROUP_STATUS 0) itemoff 16251 itemsize 32
version 1 generation 13 flags ON scan 213827585
item 1 key (0 QGROUP_INFO 0/5) itemoff 16211 itemsize 40
generation 11
referenced 170999808 referenced_compressed 170999808
exclusive 170999808 exclusive_compressed 170999808
item 2 key (0 QGROUP_LIMIT 0/5) itemoff 16171 itemsize 40
flags 0
max_referenced 0 max_exclusive 0
rsv_referenced 0 rsv_exclusive 0
total bytes 26843545600
bytes used 171769856
uuid d07f6028-0ae7-40d4-ac45-01a4505ddcfb
>
> Thanks,
> Qu>
>>
>> My observation is that this commit changed to call initial quota rescan
>> when quota is enabeld instead of first comit transaction after enabling
>> quota, and therefore if there is something not commited at that time,
>> their usage will not be accounted.
>>
>> Actually this can be simply fixed by calling "btrfs rescan" again or
>> calling "btrfs fi sync" bef
Re: Enabling quota may not correctly rescan on 4.17
On 27.06.2018 11:20, Misono Tomohiro wrote: > I can see the failure with or without options... > maybe it depends on machine spec? I'm testing in a virtual machine: qemu-system-x86_64 -smp 6 -kernel /home/nborisov/projects/kernel/source/arch/x86_64/boot/bzImage -append root=/dev/vda rw -enable-kvm -m 4096 -drive file=/home/nborisov/projects/qemu/rootfs/ubuntu15.img,if=virtio -virtfs local,id=fsdev1,path=/mnt/vm_share,security_model=passthrough,mount_tag=hostshare -drive file=/home/nborisov/scratch/scratch-images/btrfs-test.img,if=virtio -drive file=/home/nborisov/scratch/scratch-images/scratch2.img,if=virtio -drive file=/home/nborisov/scratch/scratch-images/scratch3.img,if=virtio -drive file=/home/nborisov/scratch/scratch-images/scratch4.img,if=virtio -drive file=/home/nborisov/scratch/scratch-images/scratch5.img,if=virtio -drive file=/home/nborisov/scratch/scratch-images/scratch6.img,if=virtio -redir tcp:1235::22 -daemonize Perhaps it's not visible on slow storage. Are you testing on NVME or something like that? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 2018/06/27 17:04, Nikolay Borisov wrote:
>
>
> On 27.06.2018 10:55, Misono Tomohiro wrote:
>> On 2018/06/27 16:40, Nikolay Borisov wrote:
>>>
>>>
>>> On 26.06.2018 09:00, Misono Tomohiro wrote:
Hello Nikolay,
I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
to fail correctly rescanning quota when quota is enabled.
Simple reproducer:
$ mkfs.btrfs -f $DEV
$ mount $DEV /mnt
$ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
$ btrfs quota enbale /mnt
$ umount /mnt
$ btrfs check $DEV
...
checking quota groups
Counts for qgroup id: 0/5 are different
our:referenced 1019904 referenced compressed 1019904
disk: referenced 16384 referenced compressed 16384
diff: referenced 1003520 referenced compressed 1003520
our:exclusive 1019904 exclusive compressed 1019904
disk: exclusive 16384 exclusive compressed 16384
diff: exclusive 1003520 exclusive compressed 1003520
found 1413120 bytes used, error(s) found
...
>>>
>>> I ran your script 100 times with progs 4.17 and 4.18-rc1 and didn't
>>> observe this error. I didn't observe btrfs/114 also failing but I ran it
>>> a lot less. Is there anything else i can do to make your small
>>> reproducer more likely to trigger?
>>
>> How about btrfs/114? I saw the problem in it first (progs 4.17/kernel
>> 4.18-rc2)
>> and it seems always happen in my environment.
>
> So far nothing, I'm using David's github/misc-next branch, and latest
> commit is: 5330a89b3ee3.
>
> My mount options are:
>
> MOUNT_OPTIONS -- -o enospc_debug -o space_cache=v2 /dev/vdc /media/scratch
I can see the failure with or without options...
maybe it depends on machine spec?
>
>>
>>>
This can be also observed in btrfs/114. (Note that progs < 4.17
returns error code 0 even if quota is not consistency and therefore
test will incorrectly pass.)
My observation is that this commit changed to call initial quota rescan
when quota is enabeld instead of first comit transaction after enabling
quota, and therefore if there is something not commited at that time,
their usage will not be accounted.
Actually this can be simply fixed by calling "btrfs rescan" again or
calling "btrfs fi sync" before "btrfs quota enable".
I think the commit itself makes the code much easier to read, so it may
be better to fix the problem in progs (i.e. calling sync before quota
enable).
Do you have any thoughts?
Thanks,
Tomohiro Misono
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 2018年06月26日 14:00, Misono Tomohiro wrote:
> Hello Nikolay,
>
> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
> to fail correctly rescanning quota when quota is enabled.
>
> Simple reproducer:
>
> $ mkfs.btrfs -f $DEV
> $ mount $DEV /mnt
> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
> $ btrfs quota enbale /mnt
> $ umount /mnt
> $ btrfs check $DEV
> ...
> checking quota groups
> Counts for qgroup id: 0/5 are different
> our:referenced 1019904 referenced compressed 1019904
> disk: referenced 16384 referenced compressed 16384
> diff: referenced 1003520 referenced compressed 1003520
> our:exclusive 1019904 exclusive compressed 1019904
> disk: exclusive 16384 exclusive compressed 16384
> diff: exclusive 1003520 exclusive compressed 1003520
> found 1413120 bytes used, error(s) found
> ...
>
> This can be also observed in btrfs/114. (Note that progs < 4.17
> returns error code 0 even if quota is not consistency and therefore
> test will incorrectly pass.)
BTW, would you please try to dump the quota tree for such mismatch case?
It could be a btrfs-progs bug which it should skip quota checking if it
found the quota status item has RESCAN flag.
Thanks,
Qu
>
> My observation is that this commit changed to call initial quota rescan
> when quota is enabeld instead of first comit transaction after enabling
> quota, and therefore if there is something not commited at that time,
> their usage will not be accounted.
>
> Actually this can be simply fixed by calling "btrfs rescan" again or
> calling "btrfs fi sync" before "btrfs quota enable".
>
> I think the commit itself makes the code much easier to read, so it may
> be better to fix the problem in progs (i.e. calling sync before quota enable).
>
> Do you have any thoughts?
>
> Thanks,
> Tomohiro Misono
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 27.06.2018 10:55, Misono Tomohiro wrote:
> On 2018/06/27 16:40, Nikolay Borisov wrote:
>>
>>
>> On 26.06.2018 09:00, Misono Tomohiro wrote:
>>> Hello Nikolay,
>>>
>>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>>> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
>>> to fail correctly rescanning quota when quota is enabled.
>>>
>>> Simple reproducer:
>>>
>>> $ mkfs.btrfs -f $DEV
>>> $ mount $DEV /mnt
>>> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
>>> $ btrfs quota enbale /mnt
>>> $ umount /mnt
>>> $ btrfs check $DEV
>>> ...
>>> checking quota groups
>>> Counts for qgroup id: 0/5 are different
>>> our:referenced 1019904 referenced compressed 1019904
>>> disk: referenced 16384 referenced compressed 16384
>>> diff: referenced 1003520 referenced compressed 1003520
>>> our:exclusive 1019904 exclusive compressed 1019904
>>> disk: exclusive 16384 exclusive compressed 16384
>>> diff: exclusive 1003520 exclusive compressed 1003520
>>> found 1413120 bytes used, error(s) found
>>> ...
>>
>> I ran your script 100 times with progs 4.17 and 4.18-rc1 and didn't
>> observe this error. I didn't observe btrfs/114 also failing but I ran it
>> a lot less. Is there anything else i can do to make your small
>> reproducer more likely to trigger?
>
> How about btrfs/114? I saw the problem in it first (progs 4.17/kernel
> 4.18-rc2)
> and it seems always happen in my environment.
So far nothing, I'm using David's github/misc-next branch, and latest
commit is: 5330a89b3ee3.
My mount options are:
MOUNT_OPTIONS -- -o enospc_debug -o space_cache=v2 /dev/vdc /media/scratch
>
>>
>>>
>>> This can be also observed in btrfs/114. (Note that progs < 4.17
>>> returns error code 0 even if quota is not consistency and therefore
>>> test will incorrectly pass.)
>>>
>>> My observation is that this commit changed to call initial quota rescan
>>> when quota is enabeld instead of first comit transaction after enabling
>>> quota, and therefore if there is something not commited at that time,
>>> their usage will not be accounted.
>>>
>>> Actually this can be simply fixed by calling "btrfs rescan" again or
>>> calling "btrfs fi sync" before "btrfs quota enable".
>>>
>>> I think the commit itself makes the code much easier to read, so it may
>>> be better to fix the problem in progs (i.e. calling sync before quota
>>> enable).
>>>
>>> Do you have any thoughts?
>>>
>>> Thanks,
>>> Tomohiro Misono
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 2018/06/27 16:40, Nikolay Borisov wrote:
>
>
> On 26.06.2018 09:00, Misono Tomohiro wrote:
>> Hello Nikolay,
>>
>> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
>> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
>> to fail correctly rescanning quota when quota is enabled.
>>
>> Simple reproducer:
>>
>> $ mkfs.btrfs -f $DEV
>> $ mount $DEV /mnt
>> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
>> $ btrfs quota enbale /mnt
>> $ umount /mnt
>> $ btrfs check $DEV
>> ...
>> checking quota groups
>> Counts for qgroup id: 0/5 are different
>> our:referenced 1019904 referenced compressed 1019904
>> disk: referenced 16384 referenced compressed 16384
>> diff: referenced 1003520 referenced compressed 1003520
>> our:exclusive 1019904 exclusive compressed 1019904
>> disk: exclusive 16384 exclusive compressed 16384
>> diff: exclusive 1003520 exclusive compressed 1003520
>> found 1413120 bytes used, error(s) found
>> ...
>
> I ran your script 100 times with progs 4.17 and 4.18-rc1 and didn't
> observe this error. I didn't observe btrfs/114 also failing but I ran it
> a lot less. Is there anything else i can do to make your small
> reproducer more likely to trigger?
How about btrfs/114? I saw the problem in it first (progs 4.17/kernel 4.18-rc2)
and it seems always happen in my environment.
>
>>
>> This can be also observed in btrfs/114. (Note that progs < 4.17
>> returns error code 0 even if quota is not consistency and therefore
>> test will incorrectly pass.)
>>
>> My observation is that this commit changed to call initial quota rescan
>> when quota is enabeld instead of first comit transaction after enabling
>> quota, and therefore if there is something not commited at that time,
>> their usage will not be accounted.
>>
>> Actually this can be simply fixed by calling "btrfs rescan" again or
>> calling "btrfs fi sync" before "btrfs quota enable".
>>
>> I think the commit itself makes the code much easier to read, so it may
>> be better to fix the problem in progs (i.e. calling sync before quota
>> enable).
>>
>> Do you have any thoughts?
>>
>> Thanks,
>> Tomohiro Misono
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 26.06.2018 09:00, Misono Tomohiro wrote:
> Hello Nikolay,
>
> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
> to fail correctly rescanning quota when quota is enabled.
>
> Simple reproducer:
>
> $ mkfs.btrfs -f $DEV
> $ mount $DEV /mnt
> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
> $ btrfs quota enbale /mnt
> $ umount /mnt
> $ btrfs check $DEV
> ...
> checking quota groups
> Counts for qgroup id: 0/5 are different
> our:referenced 1019904 referenced compressed 1019904
> disk: referenced 16384 referenced compressed 16384
> diff: referenced 1003520 referenced compressed 1003520
> our:exclusive 1019904 exclusive compressed 1019904
> disk: exclusive 16384 exclusive compressed 16384
> diff: exclusive 1003520 exclusive compressed 1003520
> found 1413120 bytes used, error(s) found
> ...
I ran your script 100 times with progs 4.17 and 4.18-rc1 and didn't
observe this error. I didn't observe btrfs/114 also failing but I ran it
a lot less. Is there anything else i can do to make your small
reproducer more likely to trigger?
>
> This can be also observed in btrfs/114. (Note that progs < 4.17
> returns error code 0 even if quota is not consistency and therefore
> test will incorrectly pass.)
>
> My observation is that this commit changed to call initial quota rescan
> when quota is enabeld instead of first comit transaction after enabling
> quota, and therefore if there is something not commited at that time,
> their usage will not be accounted.
>
> Actually this can be simply fixed by calling "btrfs rescan" again or
> calling "btrfs fi sync" before "btrfs quota enable".
>
> I think the commit itself makes the code much easier to read, so it may
> be better to fix the problem in progs (i.e. calling sync before quota enable).
>
> Do you have any thoughts?
>
> Thanks,
> Tomohiro Misono
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling quota may not correctly rescan on 4.17
On 26.06.2018 09:00, Misono Tomohiro wrote:
> Hello Nikolay,
>
> I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
> on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
> to fail correctly rescanning quota when quota is enabled.
Everytime I hear anything quota-related and I cringe ...
>
> Simple reproducer:
>
> $ mkfs.btrfs -f $DEV
> $ mount $DEV /mnt
> $ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
> $ btrfs quota enbale /mnt
> $ umount /mnt
> $ btrfs check $DEV
> ...
> checking quota groups
> Counts for qgroup id: 0/5 are different
> our:referenced 1019904 referenced compressed 1019904
> disk: referenced 16384 referenced compressed 16384
> diff: referenced 1003520 referenced compressed 1003520
> our:exclusive 1019904 exclusive compressed 1019904
> disk: exclusive 16384 exclusive compressed 16384
> diff: exclusive 1003520 exclusive compressed 1003520
> found 1413120 bytes used, error(s) found
> ...
>
> This can be also observed in btrfs/114. (Note that progs < 4.17
> returns error code 0 even if quota is not consistency and therefore
> test will incorrectly pass.)
>
> My observation is that this commit changed to call initial quota rescan
> when quota is enabeld instead of first comit transaction after enabling
> quota, and therefore if there is something not commited at that time,
> their usage will not be accounted.
>
> Actually this can be simply fixed by calling "btrfs rescan" again or
> calling "btrfs fi sync" before "btrfs quota enable".
>
> I think the commit itself makes the code much easier to read, so it may
> be better to fix the problem in progs (i.e. calling sync before quota enable).
>
> Do you have any thoughts?
So fixing it in progs will indeed work, however any 3rd party code which
relies on the scan/enable ioctl will be "broken" so that's not good.
Ideally the correct thing should be that quota scanning can also take
into account the in-memory state i.e any delayed refs but I think this
will be way too much work.
Alternatively, what about moving the transaction start from
btrfs_ioctl_quota_ctl to btrfs_quota_enable/btrfs_quota_disable
functions. That way what we can do is perform the transaction commit in
btrfs_quota_enable before queuing the rescan?
>
> Thanks,
> Tomohiro Misono
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
