* Confused by btrfs quota group accounting
@ 2019-06-22 15:11 Andrei Borzenkov
2019-06-23 7:55 ` Qu Wenruo
0 siblings, 1 reply; 7+ messages in thread
From: Andrei Borzenkov @ 2019-06-22 15:11 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org
Linux 10.0.2.15 5.1.7-1-default #1 SMP Tue Jun 4 07:56:54 UTC 2019
(55f2451) x86_64 x86_64 x86_64 GNU/Linux
Consider the following:
10:~ # mkfs.btrfs -f /dev/vdb /dev/vdc
btrfs-progs v5.1
See http://btrfs.wiki.kernel.org for more information.
Label: (null)
UUID: d10df0fa-25aa-4d80-89d9-16033ae3392d
Node size: 16384
Sector size: 4096
Filesystem size: 2.00GiB
Block group profiles:
Data: RAID0 204.75MiB
Metadata: RAID1 102.38MiB
System: RAID1 8.00MiB
SSD detected: no
Incompat features: extref, skinny-metadata
Number of devices: 2
Devices:
ID SIZE PATH
1 1.00GiB /dev/vdb
2 1.00GiB /dev/vdc
10:~ # mount /dev/vdb /mnt
10:~ # cd -
/mnt
10:/mnt # btrfs quota enable .
10:/mnt # btrfs sub cre test
Create subvolume './test'
10:/mnt # dd if=/dev/urandom of=test/file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 6.71373 s, 160 MB/s
10:/mnt # sync
10:/mnt # btrfs qgroup show .
qgroupid rfer excl
-------- ---- ----
0/5 16.00KiB 16.00KiB
0/258 1.00GiB 1.00GiB
10:/mnt # filefrag -v test/file
Filesystem type is: 9123683e
File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 43135: 33664.. 76799: 43136:
1: 43136.. 97279: 86048.. 140191: 54144: 76800:
2: 97280.. 151551: 143392.. 197663: 54272: 140192:
3: 151552.. 207359: 200736.. 256543: 55808: 197664:
4: 207360.. 262143: 258080.. 312863: 54784: 256544:
last,eof
test/file: 5 extents found
OK, we have 1Gib file consisting of 5 extents ~200MiB each, btrfs quota
reports 1GiB exclusive in subvolume test which is correct.
10:/mnt # btrfs subvolume snapshot -r test snap1
Create a readonly snapshot of 'test' in './snap1'
10:/mnt # sync
10:/mnt # btrfs qgroup show .
qgroupid rfer excl
-------- ---- ----
0/5 16.00KiB 16.00KiB
0/258 1.00GiB 16.00KiB
0/263 1.00GiB 16.00KiB
10:/mnt # filefrag -v test/file
Filesystem type is: 9123683e
File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 43135: 33664.. 76799: 43136: shared
1: 43136.. 97279: 86048.. 140191: 54144: 76800: shared
2: 97280.. 151551: 143392.. 197663: 54272: 140192: shared
3: 151552.. 207359: 200736.. 256543: 55808: 197664: shared
4: 207360.. 262143: 258080.. 312863: 54784: 256544:
last,shared,eof
test/file: 5 extents found
Also correct, content of test and snap1 is shared so we have two
subvolumes with zero exclusive usage. Also good.
10:/mnt # dd if=/dev/urandom of=test/file bs=1M count=100 seek=0
conv=notrunc
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.685532 s, 153 MB/s
10:/mnt # sync
10:/mnt # btrfs qgroup show .
qgroupid rfer excl
-------- ---- ----
0/5 16.00KiB 16.00KiB
0/258 1.01GiB 100.02MiB
0/263 1.00GiB 85.02MiB
10:/mnt # filefrag -v test/file
Filesystem type is: 9123683e
File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 22463: 315424.. 337887: 22464:
1: 22464.. 25599: 76896.. 80031: 3136: 337888:
2: 25600.. 43135: 59264.. 76799: 17536: 80032: shared
3: 43136.. 97279: 86048.. 140191: 54144: 76800: shared
4: 97280.. 151551: 143392.. 197663: 54272: 140192: shared
5: 151552.. 207359: 200736.. 256543: 55808: 197664: shared
6: 207360.. 262143: 258080.. 312863: 54784: 256544:
last,shared,eof
test/file: 7 extents found
10:/mnt # filefrag -v snap1/file
Filesystem type is: 9123683e
File size of snap1/file is 1073741824 (262144 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 43135: 33664.. 76799: 43136:
1: 43136.. 97279: 86048.. 140191: 54144: 76800: shared
2: 97280.. 151551: 143392.. 197663: 54272: 140192: shared
3: 151552.. 207359: 200736.. 256543: 55808: 197664: shared
4: 207360.. 262143: 258080.. 312863: 54784: 256544:
last,shared,eof
snap1/file: 5 extents found
Oops. Where 85MiB exclusive usage in snapshot comes from? I would expect
one of
- 0 exclusive, because original first extent is still referenced by test
(even though partially), so if qgroup counts physical space usage, snap1
effectively refers to the same physical extents as test.
- 100MiB exclusive if qgroup counts logical space consumption, because
snapshot now has 100MiB different data.
But 85MiB? It does not match any observed value. Judging by 1.01GiB of
referenced space for subvolume test, qrgoup counts physical usage, at
which point snapshot exclusive space consumption remains 0.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by btrfs quota group accounting
2019-06-22 15:11 Confused by btrfs quota group accounting Andrei Borzenkov
@ 2019-06-23 7:55 ` Qu Wenruo
2019-06-23 8:08 ` Qu Wenruo
0 siblings, 1 reply; 7+ messages in thread
From: Qu Wenruo @ 2019-06-23 7:55 UTC (permalink / raw)
To: Andrei Borzenkov, linux-btrfs@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 4533 bytes --]
On 2019/6/22 下午11:11, Andrei Borzenkov wrote:
[snip]
>
> 10:/mnt # dd if=/dev/urandom of=test/file bs=1M count=100 seek=0
> conv=notrunc
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB, 100 MiB) copied, 0.685532 s, 153 MB/s
> 10:/mnt # sync
> 10:/mnt # btrfs qgroup show .
> qgroupid rfer excl
> -------- ---- ----
> 0/5 16.00KiB 16.00KiB
> 0/258 1.01GiB 100.02MiB
> 0/263 1.00GiB 85.02MiB
Sorry, I can't really reproduce it.
5.1.12 kernel, using the following script:
---
#!/bin/bash
dev="/dev/data/btrfs"
mnt="/mnt/btrfs"
umount $dev &> /dev/null
mkfs.btrfs -f $dev > /dev/null
mount $dev $mnt
btrfs sub create $mnt/subv1
btrfs quota enable $mnt
btrfs quota rescan -w $mnt
xfs_io -f -c "pwrite 0 1G" $mnt/subv1/file1
sync
btrfs sub snapshot $mnt/subv1 $mnt/subv2
sync
btrfs qgroup show -prce $mnt
xfs_io -c "pwrite 0 100m" $mnt/subv1/file1
sync
btrfs qgroup show -prce $mnt
---
The result is:
---
Create subvolume '/mnt/btrfs/subv1'
wrote 1073741824/1073741824 bytes at offset 0
1 GiB, 262144 ops; 0.5902 sec (1.694 GiB/sec and 444134.2107 ops/sec)
Create a snapshot of '/mnt/btrfs/subv1' in '/mnt/btrfs/subv2'
qgroupid rfer excl max_rfer max_excl parent child
-------- ---- ---- -------- -------- ------ -----
0/5 16.00KiB 16.00KiB none none --- ---
0/256 1.00GiB 16.00KiB none none --- ---
0/259 1.00GiB 16.00KiB none none --- ---
wrote 104857600/104857600 bytes at offset 0
100 MiB, 25600 ops; 0.0694 sec (1.406 GiB/sec and 368652.9766 ops/sec)
qgroupid rfer excl max_rfer max_excl parent child
-------- ---- ---- -------- -------- ------ -----
0/5 16.00KiB 16.00KiB none none --- ---
0/256 1.10GiB 100.02MiB none none --- ---
0/259 1.00GiB 16.00KiB none none --- ---
---
> 10:/mnt # filefrag -v test/file
> Filesystem type is: 9123683e
> File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 22463: 315424.. 337887: 22464:
There is a initial 10.9MiB extent, I'm not sure how it's created.
> 1: 22464.. 25599: 76896.. 80031: 3136: 337888:
Also here comes another 1.5MiB extent.
From the result of the fiemap, it's definitely not 100MiB written.
Only 12.5M written.
The fiemap result doesn't match with your dd command.
Any clue how this happened?
Thanks,
Qu
> 2: 25600.. 43135: 59264.. 76799: 17536: 80032: shared
> 3: 43136.. 97279: 86048.. 140191: 54144: 76800: shared
> 4: 97280.. 151551: 143392.. 197663: 54272: 140192: shared
> 5: 151552.. 207359: 200736.. 256543: 55808: 197664: shared
> 6: 207360.. 262143: 258080.. 312863: 54784: 256544:
> last,shared,eof
> test/file: 7 extents found
> 10:/mnt # filefrag -v snap1/file
> Filesystem type is: 9123683e
> File size of snap1/file is 1073741824 (262144 blocks of 4096 bytes)
> ext: logical_offset: physical_offset: length: expected: flags:
> 0: 0.. 43135: 33664.. 76799: 43136:
> 1: 43136.. 97279: 86048.. 140191: 54144: 76800: shared
> 2: 97280.. 151551: 143392.. 197663: 54272: 140192: shared
> 3: 151552.. 207359: 200736.. 256543: 55808: 197664: shared
> 4: 207360.. 262143: 258080.. 312863: 54784: 256544:
> last,shared,eof
> snap1/file: 5 extents found
>
>
> Oops. Where 85MiB exclusive usage in snapshot comes from? I would expect
> one of
>
> - 0 exclusive, because original first extent is still referenced by test
> (even though partially), so if qgroup counts physical space usage, snap1
> effectively refers to the same physical extents as test.
>
> - 100MiB exclusive if qgroup counts logical space consumption, because
> snapshot now has 100MiB different data.
>
> But 85MiB? It does not match any observed value. Judging by 1.01GiB of
> referenced space for subvolume test, qrgoup counts physical usage, at
> which point snapshot exclusive space consumption remains 0.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by btrfs quota group accounting
2019-06-23 7:55 ` Qu Wenruo
@ 2019-06-23 8:08 ` Qu Wenruo
2019-06-23 10:15 ` Andrei Borzenkov
0 siblings, 1 reply; 7+ messages in thread
From: Qu Wenruo @ 2019-06-23 8:08 UTC (permalink / raw)
To: Andrei Borzenkov, linux-btrfs@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 3702 bytes --]
On 2019/6/23 下午3:55, Qu Wenruo wrote:
>
>
> On 2019/6/22 下午11:11, Andrei Borzenkov wrote:
> [snip]
>>
>> 10:/mnt # dd if=/dev/urandom of=test/file bs=1M count=100 seek=0
>> conv=notrunc
>> 100+0 records in
>> 100+0 records out
>> 104857600 bytes (105 MB, 100 MiB) copied, 0.685532 s, 153 MB/s
>> 10:/mnt # sync
>> 10:/mnt # btrfs qgroup show .
>> qgroupid rfer excl
>> -------- ---- ----
>> 0/5 16.00KiB 16.00KiB
>> 0/258 1.01GiB 100.02MiB
>> 0/263 1.00GiB 85.02MiB
>
> Sorry, I can't really reproduce it.
>
> 5.1.12 kernel, using the following script:
> ---
> #!/bin/bash
>
> dev="/dev/data/btrfs"
> mnt="/mnt/btrfs"
>
> umount $dev &> /dev/null
> mkfs.btrfs -f $dev > /dev/null
>
> mount $dev $mnt
> btrfs sub create $mnt/subv1
> btrfs quota enable $mnt
> btrfs quota rescan -w $mnt
>
> xfs_io -f -c "pwrite 0 1G" $mnt/subv1/file1
> sync
> btrfs sub snapshot $mnt/subv1 $mnt/subv2
> sync
> btrfs qgroup show -prce $mnt
>
> xfs_io -c "pwrite 0 100m" $mnt/subv1/file1
> sync
> btrfs qgroup show -prce $mnt
> ---
>
> The result is:
> ---
> Create subvolume '/mnt/btrfs/subv1'
> wrote 1073741824/1073741824 bytes at offset 0
> 1 GiB, 262144 ops; 0.5902 sec (1.694 GiB/sec and 444134.2107 ops/sec)
> Create a snapshot of '/mnt/btrfs/subv1' in '/mnt/btrfs/subv2'
> qgroupid rfer excl max_rfer max_excl parent child
> -------- ---- ---- -------- -------- ------ -----
> 0/5 16.00KiB 16.00KiB none none --- ---
> 0/256 1.00GiB 16.00KiB none none --- ---
> 0/259 1.00GiB 16.00KiB none none --- ---
> wrote 104857600/104857600 bytes at offset 0
> 100 MiB, 25600 ops; 0.0694 sec (1.406 GiB/sec and 368652.9766 ops/sec)
> qgroupid rfer excl max_rfer max_excl parent child
> -------- ---- ---- -------- -------- ------ -----
> 0/5 16.00KiB 16.00KiB none none --- ---
> 0/256 1.10GiB 100.02MiB none none --- ---
> 0/259 1.00GiB 16.00KiB none none --- ---
> ---
>
>> 10:/mnt # filefrag -v test/file
>> Filesystem type is: 9123683e
>> File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
My bad, I'm still using 512 bytes as blocksize.
If using 4K blocksize, then the fiemap result matches.
Then please discard my previous comment.
Then we need to check data extents layout to make sure what's going on.
Would you please provide the following output?
# btrfs ins dump-tree -t 258 /dev/vdb
# btrfs ins dump-tree -t 263 /dev/vdb
# btrfs check /dev/vdb
If the last command reports qgroup mismatch, then it means qgroup is
indeed incorrect.
Also, I see your subvolume id is not continuous, did you created/removed
some other subvolumes during your test?
Thanks,
Qu
>> Oops. Where 85MiB exclusive usage in snapshot comes from? I would expect
>> one of
>>
>> - 0 exclusive, because original first extent is still referenced by test
>> (even though partially), so if qgroup counts physical space usage, snap1
>> effectively refers to the same physical extents as test.
>>
>> - 100MiB exclusive if qgroup counts logical space consumption, because
>> snapshot now has 100MiB different data.
>>
>> But 85MiB? It does not match any observed value. Judging by 1.01GiB of
>> referenced space for subvolume test, qrgoup counts physical usage, at
>> which point snapshot exclusive space consumption remains 0.
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by btrfs quota group accounting
2019-06-23 8:08 ` Qu Wenruo
@ 2019-06-23 10:15 ` Andrei Borzenkov
2019-06-23 11:29 ` Qu Wenruo
0 siblings, 1 reply; 7+ messages in thread
From: Andrei Borzenkov @ 2019-06-23 10:15 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 25871 bytes --]
23.06.2019 11:08, Qu Wenruo пишет:
>
>
> On 2019/6/23 下午3:55, Qu Wenruo wrote:
>>
>>
>> On 2019/6/22 下午11:11, Andrei Borzenkov wrote:
>> [snip]
>>>
>>> 10:/mnt # dd if=/dev/urandom of=test/file bs=1M count=100 seek=0
>>> conv=notrunc
>>> 100+0 records in
>>> 100+0 records out
>>> 104857600 bytes (105 MB, 100 MiB) copied, 0.685532 s, 153 MB/s
>>> 10:/mnt # sync
>>> 10:/mnt # btrfs qgroup show .
>>> qgroupid rfer excl
>>> -------- ---- ----
>>> 0/5 16.00KiB 16.00KiB
>>> 0/258 1.01GiB 100.02MiB
>>> 0/263 1.00GiB 85.02MiB
>>
>> Sorry, I can't really reproduce it.
>>
>> 5.1.12 kernel, using the following script:
>> ---
>> #!/bin/bash
>>
>> dev="/dev/data/btrfs"
>> mnt="/mnt/btrfs"
>>
>> umount $dev &> /dev/null
>> mkfs.btrfs -f $dev > /dev/null
>>
>> mount $dev $mnt
>> btrfs sub create $mnt/subv1
>> btrfs quota enable $mnt
>> btrfs quota rescan -w $mnt
>>
>> xfs_io -f -c "pwrite 0 1G" $mnt/subv1/file1
>> sync
>> btrfs sub snapshot $mnt/subv1 $mnt/subv2
>> sync
>> btrfs qgroup show -prce $mnt
>>
>> xfs_io -c "pwrite 0 100m" $mnt/subv1/file1
>> sync
>> btrfs qgroup show -prce $mnt
>> ---
>>
>> The result is:
>> ---
>> Create subvolume '/mnt/btrfs/subv1'
>> wrote 1073741824/1073741824 bytes at offset 0
>> 1 GiB, 262144 ops; 0.5902 sec (1.694 GiB/sec and 444134.2107 ops/sec)
>> Create a snapshot of '/mnt/btrfs/subv1' in '/mnt/btrfs/subv2'
>> qgroupid rfer excl max_rfer max_excl parent child
>> -------- ---- ---- -------- -------- ------ -----
>> 0/5 16.00KiB 16.00KiB none none --- ---
>> 0/256 1.00GiB 16.00KiB none none --- ---
>> 0/259 1.00GiB 16.00KiB none none --- ---
>> wrote 104857600/104857600 bytes at offset 0
>> 100 MiB, 25600 ops; 0.0694 sec (1.406 GiB/sec and 368652.9766 ops/sec)
>> qgroupid rfer excl max_rfer max_excl parent child
>> -------- ---- ---- -------- -------- ------ -----
>> 0/5 16.00KiB 16.00KiB none none --- ---
>> 0/256 1.10GiB 100.02MiB none none --- ---
>> 0/259 1.00GiB 16.00KiB none none --- ---
>> ---
>>
>>> 10:/mnt # filefrag -v test/file
>>> Filesystem type is: 9123683e
>>> File size of test/file is 1073741824 (262144 blocks of 4096 bytes)
>
> My bad, I'm still using 512 bytes as blocksize.
> If using 4K blocksize, then the fiemap result matches.
>
> Then please discard my previous comment.
>
> Then we need to check data extents layout to make sure what's going on.
>
> Would you please provide the following output?
> # btrfs ins dump-tree -t 258 /dev/vdb
> # btrfs ins dump-tree -t 263 /dev/vdb
> # btrfs check /dev/vdb
>
> If the last command reports qgroup mismatch, then it means qgroup is
> indeed incorrect.
>
no error reported.
10:/home/bor # btrfs ins dump-tree -t 258 /dev/vdb
btrfs-progs v5.1
file tree key (258 ROOT_ITEM 0)
leaf 32505856 items 45 free space 12677 generation 11 owner 258
leaf 32505856 flags 0x1(WRITTEN) backref revision 1
fs uuid d10df0fa-25aa-4d80-89d9-16033ae3392d
chunk uuid 1bf7922a-9f98-4c76-8511-77e5605b8112
item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
generation 8 transid 9 size 8 nbytes 0
block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0
sequence 13 flags 0x0(none)
atime 1561214496.783636682 (2019-06-22 17:41:36)
ctime 1561214504.7643132 (2019-06-22 17:41:44)
mtime 1561214504.7643132 (2019-06-22 17:41:44)
otime 1561214496.783636682 (2019-06-22 17:41:36)
item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
index 0 namelen 2 name: ..
item 2 key (256 DIR_ITEM 1847562484) itemoff 16077 itemsize 34
location key (257 INODE_ITEM 0) type FILE
transid 9 data_len 0 name_len 4
name: file
item 3 key (256 DIR_INDEX 2) itemoff 16043 itemsize 34
location key (257 INODE_ITEM 0) type FILE
transid 9 data_len 0 name_len 4
name: file
item 4 key (257 INODE_ITEM 0) itemoff 15883 itemsize 160
generation 9 transid 11 size 1073741824 nbytes 1073741824
block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
sequence 1136 flags 0x0(none)
atime 1561214504.7643132 (2019-06-22 17:41:44)
ctime 1561214563.71728522 (2019-06-22 17:42:43)
mtime 1561214563.71728522 (2019-06-22 17:42:43)
otime 1561214504.7643132 (2019-06-22 17:41:44)
item 5 key (257 INODE_REF 256) itemoff 15869 itemsize 14
index 2 namelen 4 name: file
item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53
generation 11 type 1 (regular)
extent data disk byte 1291976704 nr 46137344
extent data offset 0 nr 46137344 ram 46137344
extent compression 0 (none)
item 7 key (257 EXTENT_DATA 46137344) itemoff 15763 itemsize 53
generation 11 type 1 (regular)
extent data disk byte 1338114048 nr 45875200
extent data offset 0 nr 45875200 ram 45875200
extent compression 0 (none)
item 8 key (257 EXTENT_DATA 92012544) itemoff 15710 itemsize 53
generation 11 type 1 (regular)
extent data disk byte 314966016 nr 262144
extent data offset 0 nr 262144 ram 262144
extent compression 0 (none)
item 9 key (257 EXTENT_DATA 92274688) itemoff 15657 itemsize 53
generation 11 type 1 (regular)
extent data disk byte 315228160 nr 12582912
extent data offset 0 nr 12582912 ram 12582912
extent compression 0 (none)
item 10 key (257 EXTENT_DATA 104857600) itemoff 15604 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 227016704 nr 43515904
extent data offset 15728640 nr 27787264 ram 43515904
extent compression 0 (none)
item 11 key (257 EXTENT_DATA 132644864) itemoff 15551 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 270532608 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 12 key (257 EXTENT_DATA 133169152) itemoff 15498 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 271056896 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 13 key (257 EXTENT_DATA 176685056) itemoff 15445 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 352452608 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 14 key (257 EXTENT_DATA 220200960) itemoff 15392 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 395968512 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 15 key (257 EXTENT_DATA 263716864) itemoff 15339 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 439484416 nr 43778048
extent data offset 0 nr 43778048 ram 43778048
extent compression 0 (none)
item 16 key (257 EXTENT_DATA 307494912) itemoff 15286 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 483262464 nr 786432
extent data offset 0 nr 786432 ram 786432
extent compression 0 (none)
item 17 key (257 EXTENT_DATA 308281344) itemoff 15233 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 484048896 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 18 key (257 EXTENT_DATA 351797248) itemoff 15180 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 527564800 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 19 key (257 EXTENT_DATA 352321536) itemoff 15127 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 528089088 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 20 key (257 EXTENT_DATA 396886016) itemoff 15074 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 572653568 nr 1572864
extent data offset 0 nr 1572864 ram 1572864
extent compression 0 (none)
item 21 key (257 EXTENT_DATA 398458880) itemoff 15021 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 587333632 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 22 key (257 EXTENT_DATA 441974784) itemoff 14968 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 630849536 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 23 key (257 EXTENT_DATA 442499072) itemoff 14915 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 631373824 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 24 key (257 EXTENT_DATA 487063552) itemoff 14862 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 675938304 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 25 key (257 EXTENT_DATA 487587840) itemoff 14809 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 676462592 nr 43778048
extent data offset 0 nr 43778048 ram 43778048
extent compression 0 (none)
item 26 key (257 EXTENT_DATA 531365888) itemoff 14756 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 720240640 nr 262144
extent data offset 0 nr 262144 ram 262144
extent compression 0 (none)
item 27 key (257 EXTENT_DATA 531628032) itemoff 14703 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 720502784 nr 44040192
extent data offset 0 nr 44040192 ram 44040192
extent compression 0 (none)
item 28 key (257 EXTENT_DATA 575668224) itemoff 14650 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 764542976 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 29 key (257 EXTENT_DATA 620232704) itemoff 14597 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 809107456 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 30 key (257 EXTENT_DATA 620756992) itemoff 14544 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 822214656 nr 44302336
extent data offset 0 nr 44302336 ram 44302336
extent compression 0 (none)
item 31 key (257 EXTENT_DATA 665059328) itemoff 14491 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 866516992 nr 44826624
extent data offset 0 nr 44826624 ram 44826624
extent compression 0 (none)
item 32 key (257 EXTENT_DATA 709885952) itemoff 14438 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 911343616 nr 1572864
extent data offset 0 nr 1572864 ram 1572864
extent compression 0 (none)
item 33 key (257 EXTENT_DATA 711458816) itemoff 14385 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 912916480 nr 45088768
extent data offset 0 nr 45088768 ram 45088768
extent compression 0 (none)
item 34 key (257 EXTENT_DATA 756547584) itemoff 14332 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 958005248 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 35 key (257 EXTENT_DATA 757071872) itemoff 14279 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 958529536 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 36 key (257 EXTENT_DATA 801636352) itemoff 14226 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1003094016 nr 1572864
extent data offset 0 nr 1572864 ram 1572864
extent compression 0 (none)
item 37 key (257 EXTENT_DATA 803209216) itemoff 14173 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1004666880 nr 45088768
extent data offset 0 nr 45088768 ram 45088768
extent compression 0 (none)
item 38 key (257 EXTENT_DATA 848297984) itemoff 14120 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1049755648 nr 1048576
extent data offset 0 nr 1048576 ram 1048576
extent compression 0 (none)
item 39 key (257 EXTENT_DATA 849346560) itemoff 14067 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1057095680 nr 45350912
extent data offset 0 nr 45350912 ram 45350912
extent compression 0 (none)
item 40 key (257 EXTENT_DATA 894697472) itemoff 14014 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1102446592 nr 44826624
extent data offset 0 nr 44826624 ram 44826624
extent compression 0 (none)
item 41 key (257 EXTENT_DATA 939524096) itemoff 13961 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1147273216 nr 45613056
extent data offset 0 nr 45613056 ram 45613056
extent compression 0 (none)
item 42 key (257 EXTENT_DATA 985137152) itemoff 13908 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1192886272 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 43 key (257 EXTENT_DATA 985661440) itemoff 13855 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1193410560 nr 45088768
extent data offset 0 nr 45088768 ram 45088768
extent compression 0 (none)
item 44 key (257 EXTENT_DATA 1030750208) itemoff 13802 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1238499328 nr 42991616
extent data offset 0 nr 42991616 ram 42991616
extent compression 0 (none)
total bytes 2147483648
bytes used 1180483584
uuid d10df0fa-25aa-4d80-89d9-16033ae3392d
10:/home/bor # btrfs ins dump-tree -t 263 /dev/vdb
btrfs-progs v5.1
file tree key (263 ROOT_ITEM 10)
leaf 32112640 items 45 free space 12677 generation 10 owner 263
leaf 32112640 flags 0x1(WRITTEN) backref revision 1
fs uuid d10df0fa-25aa-4d80-89d9-16033ae3392d
chunk uuid 1bf7922a-9f98-4c76-8511-77e5605b8112
item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
generation 8 transid 9 size 8 nbytes 0
block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0
sequence 13 flags 0x0(none)
atime 1561214496.783636682 (2019-06-22 17:41:36)
ctime 1561214504.7643132 (2019-06-22 17:41:44)
mtime 1561214504.7643132 (2019-06-22 17:41:44)
otime 1561214496.783636682 (2019-06-22 17:41:36)
item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
index 0 namelen 2 name: ..
item 2 key (256 DIR_ITEM 1847562484) itemoff 16077 itemsize 34
location key (257 INODE_ITEM 0) type FILE
transid 9 data_len 0 name_len 4
name: file
item 3 key (256 DIR_INDEX 2) itemoff 16043 itemsize 34
location key (257 INODE_ITEM 0) type FILE
transid 9 data_len 0 name_len 4
name: file
item 4 key (257 INODE_ITEM 0) itemoff 15883 itemsize 160
generation 9 transid 9 size 1073741824 nbytes 1073741824
block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
sequence 1036 flags 0x0(none)
atime 1561214504.7643132 (2019-06-22 17:41:44)
ctime 1561214510.719648638 (2019-06-22 17:41:50)
mtime 1561214510.719648638 (2019-06-22 17:41:50)
otime 1561214504.7643132 (2019-06-22 17:41:44)
item 5 key (257 INODE_REF 256) itemoff 15869 itemsize 14
index 2 namelen 4 name: file
item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 137887744 nr 43778048
extent data offset 0 nr 43778048 ram 43778048
extent compression 0 (none)
item 7 key (257 EXTENT_DATA 43778048) itemoff 15763 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 181665792 nr 1310720
extent data offset 0 nr 1310720 ram 1310720
extent compression 0 (none)
item 8 key (257 EXTENT_DATA 45088768) itemoff 15710 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 182976512 nr 43778048
extent data offset 0 nr 43778048 ram 43778048
extent compression 0 (none)
item 9 key (257 EXTENT_DATA 88866816) itemoff 15657 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 226754560 nr 262144
extent data offset 0 nr 262144 ram 262144
extent compression 0 (none)
item 10 key (257 EXTENT_DATA 89128960) itemoff 15604 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 227016704 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 11 key (257 EXTENT_DATA 132644864) itemoff 15551 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 270532608 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 12 key (257 EXTENT_DATA 133169152) itemoff 15498 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 271056896 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 13 key (257 EXTENT_DATA 176685056) itemoff 15445 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 352452608 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 14 key (257 EXTENT_DATA 220200960) itemoff 15392 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 395968512 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 15 key (257 EXTENT_DATA 263716864) itemoff 15339 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 439484416 nr 43778048
extent data offset 0 nr 43778048 ram 43778048
extent compression 0 (none)
item 16 key (257 EXTENT_DATA 307494912) itemoff 15286 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 483262464 nr 786432
extent data offset 0 nr 786432 ram 786432
extent compression 0 (none)
item 17 key (257 EXTENT_DATA 308281344) itemoff 15233 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 484048896 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 18 key (257 EXTENT_DATA 351797248) itemoff 15180 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 527564800 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 19 key (257 EXTENT_DATA 352321536) itemoff 15127 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 528089088 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 20 key (257 EXTENT_DATA 396886016) itemoff 15074 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 572653568 nr 1572864
extent data offset 0 nr 1572864 ram 1572864
extent compression 0 (none)
item 21 key (257 EXTENT_DATA 398458880) itemoff 15021 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 587333632 nr 43515904
extent data offset 0 nr 43515904 ram 43515904
extent compression 0 (none)
item 22 key (257 EXTENT_DATA 441974784) itemoff 14968 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 630849536 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 23 key (257 EXTENT_DATA 442499072) itemoff 14915 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 631373824 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 24 key (257 EXTENT_DATA 487063552) itemoff 14862 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 675938304 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 25 key (257 EXTENT_DATA 487587840) itemoff 14809 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 676462592 nr 43778048
extent data offset 0 nr 43778048 ram 43778048
extent compression 0 (none)
item 26 key (257 EXTENT_DATA 531365888) itemoff 14756 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 720240640 nr 262144
extent data offset 0 nr 262144 ram 262144
extent compression 0 (none)
item 27 key (257 EXTENT_DATA 531628032) itemoff 14703 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 720502784 nr 44040192
extent data offset 0 nr 44040192 ram 44040192
extent compression 0 (none)
item 28 key (257 EXTENT_DATA 575668224) itemoff 14650 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 764542976 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 29 key (257 EXTENT_DATA 620232704) itemoff 14597 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 809107456 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 30 key (257 EXTENT_DATA 620756992) itemoff 14544 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 822214656 nr 44302336
extent data offset 0 nr 44302336 ram 44302336
extent compression 0 (none)
item 31 key (257 EXTENT_DATA 665059328) itemoff 14491 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 866516992 nr 44826624
extent data offset 0 nr 44826624 ram 44826624
extent compression 0 (none)
item 32 key (257 EXTENT_DATA 709885952) itemoff 14438 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 911343616 nr 1572864
extent data offset 0 nr 1572864 ram 1572864
extent compression 0 (none)
item 33 key (257 EXTENT_DATA 711458816) itemoff 14385 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 912916480 nr 45088768
extent data offset 0 nr 45088768 ram 45088768
extent compression 0 (none)
item 34 key (257 EXTENT_DATA 756547584) itemoff 14332 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 958005248 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 35 key (257 EXTENT_DATA 757071872) itemoff 14279 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 958529536 nr 44564480
extent data offset 0 nr 44564480 ram 44564480
extent compression 0 (none)
item 36 key (257 EXTENT_DATA 801636352) itemoff 14226 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1003094016 nr 1572864
extent data offset 0 nr 1572864 ram 1572864
extent compression 0 (none)
item 37 key (257 EXTENT_DATA 803209216) itemoff 14173 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1004666880 nr 45088768
extent data offset 0 nr 45088768 ram 45088768
extent compression 0 (none)
item 38 key (257 EXTENT_DATA 848297984) itemoff 14120 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1049755648 nr 1048576
extent data offset 0 nr 1048576 ram 1048576
extent compression 0 (none)
item 39 key (257 EXTENT_DATA 849346560) itemoff 14067 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1057095680 nr 45350912
extent data offset 0 nr 45350912 ram 45350912
extent compression 0 (none)
item 40 key (257 EXTENT_DATA 894697472) itemoff 14014 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1102446592 nr 44826624
extent data offset 0 nr 44826624 ram 44826624
extent compression 0 (none)
item 41 key (257 EXTENT_DATA 939524096) itemoff 13961 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1147273216 nr 45613056
extent data offset 0 nr 45613056 ram 45613056
extent compression 0 (none)
item 42 key (257 EXTENT_DATA 985137152) itemoff 13908 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1192886272 nr 524288
extent data offset 0 nr 524288 ram 524288
extent compression 0 (none)
item 43 key (257 EXTENT_DATA 985661440) itemoff 13855 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1193410560 nr 45088768
extent data offset 0 nr 45088768 ram 45088768
extent compression 0 (none)
item 44 key (257 EXTENT_DATA 1030750208) itemoff 13802 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 1238499328 nr 42991616
extent data offset 0 nr 42991616 ram 42991616
extent compression 0 (none)
total bytes 2147483648
bytes used 1180483584
uuid d10df0fa-25aa-4d80-89d9-16033ae3392d
10:/home/bor # btrfs check /dev/vdb
Opening filesystem to check...
Checking filesystem on /dev/vdb
UUID: d10df0fa-25aa-4d80-89d9-16033ae3392d
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups
found 1180483584 bytes used, no error found
total csum bytes: 1150976
total tree bytes: 1425408
total fs tree bytes: 65536
total extent tree bytes: 16384
btree space waste bytes: 231695
file data blocks allocated: 2163671040
referenced 2147942400
10:/home/bor #
> Also, I see your subvolume id is not continuous, did you created/removed
> some other subvolumes during your test?
>
No. At least on this filesystem. I have recreated it several times, but
since the last mkfs these were the only two subvolumes I created myself.
> Thanks,
> Qu
>
>>> Oops. Where 85MiB exclusive usage in snapshot comes from? I would expect
>>> one of
>>>
>>> - 0 exclusive, because original first extent is still referenced by test
>>> (even though partially), so if qgroup counts physical space usage, snap1
>>> effectively refers to the same physical extents as test.
>>>
>>> - 100MiB exclusive if qgroup counts logical space consumption, because
>>> snapshot now has 100MiB different data.
>>>
>>> But 85MiB? It does not match any observed value. Judging by 1.01GiB of
>>> referenced space for subvolume test, qrgoup counts physical usage, at
Actually 100MiB is 0.1GiB, not 0.01GiB, so this conclusion is wrong. At
which point I'm even more confused what qgroup really counts :)
>>> which point snapshot exclusive space consumption remains 0.
>>>
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by btrfs quota group accounting
2019-06-23 10:15 ` Andrei Borzenkov
@ 2019-06-23 11:29 ` Qu Wenruo
2019-06-23 13:42 ` Andrei Borzenkov
0 siblings, 1 reply; 7+ messages in thread
From: Qu Wenruo @ 2019-06-23 11:29 UTC (permalink / raw)
To: Andrei Borzenkov, linux-btrfs@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 4702 bytes --]
On 2019/6/23 下午6:15, Andrei Borzenkov wrote:
[snip]
>> If the last command reports qgroup mismatch, then it means qgroup is
>> indeed incorrect.
>>
>
> no error reported.
Then it's not a bug, and should be caused by btrfs extent booking behavior.
> 10:/home/bor # btrfs ins dump-tree -t 258 /dev/vdb
> btrfs-progs v5.1
> file tree key (258 ROOT_ITEM 0)
> item 5 key (257 INODE_REF 256) itemoff 15869 itemsize 14
> index 2 namelen 4 name: file
The inode we care about.
> item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53
> generation 11 type 1 (regular)
> extent data disk byte 1291976704 nr 46137344
> extent data offset 0 nr 46137344 ram 46137344
44 MiB extent, this should be exclusive for the subvol 258.
> item 7 key (257 EXTENT_DATA 46137344) itemoff 15763 itemsize 53
> generation 11 type 1 (regular)
> extent data disk byte 1338114048 nr 45875200
> extent data offset 0 nr 45875200 ram 45875200
Another 43.75 Mib extent, also exclusive for 258.
> item 8 key (257 EXTENT_DATA 92012544) itemoff 15710 itemsize 53
> generation 11 type 1 (regular)
> extent data disk byte 314966016 nr 262144
> extent data offset 0 nr 262144 ram 262144
Another 0.25MiB extent. Also exclusive.
> item 9 key (257 EXTENT_DATA 92274688) itemoff 15657 itemsize 53
> generation 11 type 1 (regular)
> extent data disk byte 315228160 nr 12582912
> extent data offset 0 nr 12582912 ram 12582912
Another 12.0 MiB extent, also exclusive.
BTW, so many fragmented extents, this normally means your system has
very high memory pressure or lack of memory, or lack of on-disk space.
Above 100MiB should be in one large extent, not split into so many small
ones.
So 258 have 100 MiB extents exclusive. No problem so far.
> item 10 key (257 EXTENT_DATA 104857600) itemoff 15604 itemsize 53
> generation 9 type 1 (regular)
> extent data disk byte 227016704 nr 43515904
> extent data offset 15728640 nr 27787264 ram 43515904
From this extents on, data extent at 227016704 (len 41.5M) are all
shared with another extent.
You can just search the bytenr 227016704, which also shows up in subvol 265.
[snip]
> file tree key (263 ROOT_ITEM 10)
> item 5 key (257 INODE_REF 256) itemoff 15869 itemsize 14
> index 2 namelen 4 name: file
Starts from here, that's the inode we care.
> item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53
> generation 9 type 1 (regular)
> extent data disk byte 137887744 nr 43778048
> extent data offset 0 nr 43778048 ram 43778048
Exclusive, 41.75 MiB.
> item 7 key (257 EXTENT_DATA 43778048) itemoff 15763 itemsize 53
> generation 9 type 1 (regular)
> extent data disk byte 181665792 nr 1310720
> extent data offset 0 nr 1310720 ram 1310720
Exclusive 1.25MiB.
> item 8 key (257 EXTENT_DATA 45088768) itemoff 15710 itemsize 53
> generation 9 type 1 (regular)
> extent data disk byte 182976512 nr 43778048
> extent data offset 0 nr 43778048 ram 43778048
Exclusive, 41.76 NiB.
> item 9 key (257 EXTENT_DATA 88866816) itemoff 15657 itemsize 53
> generation 9 type 1 (regular)
> extent data disk byte 226754560 nr 262144
> extent data offset 0 nr 262144 ram 262144
> extent compression 0 (none)
This data extent get shared between subvol 258 and 263.
The difference is, subvol 258 only shared part of the extent, while 263
are using the full extent.
Btrfs qgroup calculates exclusive based on extents, not bytes, so even
only part of the extent get shared, it's still counted as shared.
So for subvol 263, your exclusive is 41.75 + 1.25 + 41.76 = 84.75 MiB.
In short, due to qgroup works at extents level, not bytes level, you'll
find strange behavior.
E.g. For my previous script, if on a system with enough free memory, if
you only writes 100 MiB, which is smaller than data extent size limit
(128MiB), only one subvolume will get 100MiB exclusive while the other
one has no exclusive (except the 16K leaf).
But if you're writing 128MiB, just at the extent size limit, then both
subvolume will have 128MiB exclusive.
Thanks,
Qu
> item 10 key (257 EXTENT_DATA 89128960) itemoff 15604 itemsize 53
> generation 9 type 1 (regular)
> extent data disk byte 227016704 nr 43515904
> extent data offset 0 nr 43515904 ram 43515904
> extent compression 0 (none)
[snip]
>
>> Also, I see your subvolume id is not continuous, did you created/removed
>> some other subvolumes during your test?
>>
>
> No. At least on this filesystem. I have recreated it several times, but
> since the last mkfs these were the only two subvolumes I created myself.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by btrfs quota group accounting
2019-06-23 11:29 ` Qu Wenruo
@ 2019-06-23 13:42 ` Andrei Borzenkov
2019-06-23 13:55 ` Qu Wenruo
0 siblings, 1 reply; 7+ messages in thread
From: Andrei Borzenkov @ 2019-06-23 13:42 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 923 bytes --]
23.06.2019 14:29, Qu Wenruo пишет:
>
>
> BTW, so many fragmented extents, this normally means your system has
> very high memory pressure or lack of memory, or lack of on-disk space.
It is 1GiB QEMU VM with vanilla Tumbleweed with GNOME desktop; nothing
runs except user GNOME session. Does it fit "high memory pressure"
definition?
> Above 100MiB should be in one large extent, not split into so many small
> ones.
>
OK, so this is where I was confused. I was sure that filefrag returns
true "physical" extent layout. It seems that in filefrag output
consecutive extents are merged giving false picture of large extent
instead of many small ones. Filefrag shows 5 ~200MiB extents, not over
30 smaller ones.
Is it how generic IOCTL is designed to work or is it something that
btrfs does internally? This *is* confusing.
In any case, thank you for clarification, this makes sense now.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Confused by btrfs quota group accounting
2019-06-23 13:42 ` Andrei Borzenkov
@ 2019-06-23 13:55 ` Qu Wenruo
0 siblings, 0 replies; 7+ messages in thread
From: Qu Wenruo @ 2019-06-23 13:55 UTC (permalink / raw)
To: Andrei Borzenkov, linux-btrfs@vger.kernel.org
[-- Attachment #1.1: Type: text/plain, Size: 2094 bytes --]
On 2019/6/23 下午9:42, Andrei Borzenkov wrote:
> 23.06.2019 14:29, Qu Wenruo пишет:
>>
>>
>> BTW, so many fragmented extents, this normally means your system has
>> very high memory pressure or lack of memory, or lack of on-disk space.
>
> It is 1GiB QEMU VM with vanilla Tumbleweed with GNOME desktop; nothing
> runs except user GNOME session. Does it fit "high memory pressure"
> definition?
1GiB Vram? That's very easy to trigger memory pressure.
I'm not 100% sure about the percentage page cache can use, but 1/8 would
be a safe guess.
Which means, you can only write at most 128M before triggering writeback.
Considering other program uses some page cache, you have less available
page caches for filesystem.
>
>> Above 100MiB should be in one large extent, not split into so many small
>> ones.
>>
>
> OK, so this is where I was confused. I was sure that filefrag returns
> true "physical" extent layout. It seems that in filefrag output
> consecutive extents are merged giving false picture of large extent
> instead of many small ones. Filefrag shows 5 ~200MiB extents, not over
> 30 smaller ones.
Btrfs does file extent mapping merge at fiemap reporting time.
Personally speaking, I don't know why user would expect real extent mapping.
As long as the all these extents have the same flags, continuous
address, then merging them shouldn't be a problem.
In fact, after viewing the real on-disk extent mapping, it's possible to
explain just by the fiemap result, but using fiemap result alone is
indeed much harder to expose such case.
For your use case, it's already deep into the implementation, thus I
recommend low level tools like "btrfs ins dump-tree" to discover the
underlying extent mapping.
>
> Is it how generic IOCTL is designed to work or is it something that
> btrfs does internally? This *is* confusing.
>
> In any case, thank you for clarification, this makes sense now.
AFAIK, we should put this into the btrfs(5) man page as an special use
case. Along with btrfs extent booking.
Thanks,
Qu
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-06-23 13:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-06-22 15:11 Confused by btrfs quota group accounting Andrei Borzenkov
2019-06-23 7:55 ` Qu Wenruo
2019-06-23 8:08 ` Qu Wenruo
2019-06-23 10:15 ` Andrei Borzenkov
2019-06-23 11:29 ` Qu Wenruo
2019-06-23 13:42 ` Andrei Borzenkov
2019-06-23 13:55 ` Qu Wenruo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.